Project

General

Profile

Task #4877

Avatar?id=6023&size=22x22

default dataSource should use either dummy or XMLRepository

Added by Wojciech Kapcia TigaseTeam about 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
2017-02-01
Due date:
2017-04-14
% Done:

100%

Estimated time:
Database:
n/a

Description

Currently when there is no dataSource configured it should fallback to either dummy repository or, better yet, XMLRepository:

  • in case of setup we won't face exceptions related to repository;

  • it could serve as a super basic storage to run super simple test (most likely better than Derby)


Related issues

Related to Tigase XMPP Server - Bug #4876: Lots of exceptions and errors while starting the serverClosed2017-02-012017-03-31

Related to Tigase HTTP API - Feature #4880: config-type=setup implementationClosed2017-03-282017-04-28

Related to Tigase XMPP Server - Bug #4991: 'Default' Data Repo Bean causes JREClosed2017-04-13

Associated revisions

Revision 13f65cee (diff)
Added by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

#4877: support for usage of XMLRepository as in-memory repository

History

#1 Updated by Wojciech Kapcia TigaseTeam about 2 years ago

  • Related to Bug #4876: Lots of exceptions and errors while starting the server added

#2 Updated by Wojciech Kapcia TigaseTeam about 2 years ago

  • Related to Feature #4880: config-type=setup implementation added

#3 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

  • Related to Bug #4991: 'Default' Data Repo Bean causes JRE added

#4 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

  • Due date set to 2017-04-14

#5 Updated by Andrzej Wójcik IoT 1 CloudTigaseTeam almost 2 years ago

  • Status changed from New to In QA
  • Assignee changed from Andrzej Wójcik to Wojciech Kapcia

I disagree that we should fallback to any default repository implementation as we already have setup mode to start Tigase XMPP Server setup without any data source.

Adjustments to XMLRepository or DummyRepository to be able to use them for some basic tests makes sense and I adjusted XMLRepository to use newly created XMLDataSource (wrapper around XMLDB).

However main issue with usage of XMLRepository was fact that there was not implementation of MsgRepository which supported XMLRepository as a data source. I've fixed this by creation of XMLMsgReposiotry which is very simple repository which should work fine in basic usages. I've skipped implementation of MsgBroadcastRepository for XMLRepository as it is not used very often and server starts without it (only warning is generated).

But this leads to a conclusion that we need implementations of PubSubDAO@, @MessageArchiveRepository@, @MucDAO and HistoryProvider for XMLRepository if we want server to start with PubSub, MUC and Message Archive enabled (which are now enabled by default). This may require significant amount of work to implement those reposiotry interfaces for @XMLDataSource@.

Do we need this implementations? or we accept that for basic tests with XMLRepository PubSub, MUC and MA must be disabled?

#6 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam almost 2 years ago

To be honest I do not see much value on spending a lot of time on XMLRepository development. We should run tests over Tigase server with a real DB anyway. XMLRepository support should be really minimal what is absolutely necessary.

Maybe a better option would be to focus on Derby or similar support.

#7 Updated by Wojciech Kapcia TigaseTeam almost 2 years ago

  • Status changed from In QA to Feedback
  • Assignee changed from Wojciech Kapcia to Artur Hefczyc
  • % Done changed from 0 to 100

Andrzej Wójcik wrote:

Do we need this implementations? or we accept that for basic tests with XMLRepository PubSub, MUC and MA must be disabled?

I think that basic support for ad-hoc tests is enough.

Artur Hefczyc wrote:

To be honest I do not see much value on spending a lot of time on XMLRepository development. We should run tests over Tigase server with a real DB anyway. XMLRepository support should be really minimal what is absolutely necessary.

While it's true, it's kinda required for some parts of the code to have working repository and this is very handy for a unit tests (for which setting up separate database may be a hassle and it speeds up making changes without braking things); all in all this basic XMLRepository implementation is definitely handy.

Maybe a better option would be to focus on Derby or similar support.

On that note - we need Derby only for... "single machine simple deployment to show that Tigase is working" (i.e. someone wants to install it and check if/how it works). And Derby is slightly "challenging" to maintain (mostly by enforcing SP within Java code as well as difficult updates). Maybe for that end we should adopt hsqldb which while similar in principles to Apache Derby offers support for SQL user-defined stored procedures and functions so it would be more in line with other database hence less overhead to make support for Derby working.

#8 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam almost 2 years ago

  • Assignee changed from Artur Hefczyc to Wojciech Kapcia

Wojciech Kapcia wrote:

Artur Hefczyc wrote:

To be honest I do not see much value on spending a lot of time on XMLRepository development. We should run tests over Tigase server with a real DB anyway. XMLRepository support should be really minimal what is absolutely necessary.

While it's true, it's kinda required for some parts of the code to have working repository and this is very handy for a unit tests (for which setting up separate database may be a hassle and it speeds up making changes without braking things); all in all this basic XMLRepository implementation is definitely handy.

Indeed, I am only worried about 2 things:

  1. Partially working repository is not good. I can see lots of potential problems coming from the fact that XMLRepository works sometimes and does not work in other cases. At least, it would be good have a mechanism which clearly shows an error with description that XMLRepository is the source of a problem.

  2. Long-term maintenance might be expensive. Do we need a special support for each component, each new code? How do we maintain it in the future? I am afraid it might cost us a lot of time in the future to maintain it and keep up with code changes in other parts of our software.

Maybe a better option would be to focus on Derby or similar support.

On that note - we need Derby only for... "single machine simple deployment to show that Tigase is working" (i.e. someone wants to install it and check if/how it works). And Derby is slightly "challenging" to maintain (mostly by enforcing SP within Java code as well as difficult updates). Maybe for that end we should adopt hsqldb which while similar in principles to Apache Derby offers support for SQL user-defined stored procedures and functions so it would be more in line with other database hence less overhead to make support for Derby working.

I know about Derby issues. This is why I wrote "or similar". It would be good to have some, very simple and lightweight SQL database which could replace XMLRepository but it would not require that much effort to maintain.

#9 Updated by Wojciech Kapcia TigaseTeam almost 2 years ago

  • Assignee changed from Wojciech Kapcia to Artur Hefczyc

Artur Hefczyc wrote:

Wojciech Kapcia wrote:

Artur Hefczyc wrote:

To be honest I do not see much value on spending a lot of time on XMLRepository development. We should run tests over Tigase server with a real DB anyway. XMLRepository support should be really minimal what is absolutely necessary.

While it's true, it's kinda required for some parts of the code to have working repository and this is very handy for a unit tests (for which setting up separate database may be a hassle and it speeds up making changes without braking things); all in all this basic XMLRepository implementation is definitely handy.

Indeed, I am only worried about 2 things:

Partially working repository is not good. I can see lots of potential problems coming from the fact that XMLRepository works sometimes and does not work in other cases. At least, it would be good have a mechanism which clearly shows an error with description that XMLRepository is the source of a problem.

IMHO this is mostly for the unit-test purposes so whoever is writing tests (and thus utilising it) will be aware of the risk.

Long-term maintenance might be expensive. Do we need a special support for each component, each new code? How do we maintain it in the future? I am afraid it might cost us a lot of time in the future to maintain it and keep up with code changes in other parts of our software.

Bringing it up-to-speed with data-source was 2,5h (and it was needed only due to data-source introduction). Dealing with Derby weird issues (vide current problems) takes waaaay more time…

Maybe a better option would be to focus on Derby or similar support.

On that note - we need Derby only for... "single machine simple deployment to show that Tigase is working" (i.e. someone wants to install it and check if/how it works). And Derby is slightly "challenging" to maintain (mostly by enforcing SP within Java code as well as difficult updates). Maybe for that end we should adopt hsqldb which while similar in principles to Apache Derby offers support for SQL user-defined stored procedures and functions so it would be more in line with other database hence less overhead to make support for Derby working.

I know about Derby issues. This is why I wrote "or similar". It would be good to have some, very simple and lightweight SQL database which could replace XMLRepository but it would not require that much effort to maintain.

Possibly mentioned hsqldb could be such solution - it offers standard SP hence possibly less problematic support.

Should we close this issue (as it's done) and create new one to investigate replacement of Derby with hsqldb?

#10 Avatar?id=6023&size=24x24 Updated by Artur Hefczyc TigaseTeam almost 2 years ago

  • Status changed from Feedback to Closed

Your explanations Wojciech make sense and I agree with them. I am closing the ticket.

Also available in: Atom PDF