Andrzej Wójcik (Tigase) opened 9 years ago
|
|
While working on this changes we need to take care of proper JID comparison - see #4655 |
|
New schema is created for every supported database and in task #3995 for MongoDB. Schema files will port MUC history to new table and rename old one to @muc_history_old@. Separate class To make it easier there are 2 files in There are 2 important changes in this commit:
ie. keep rooms configurations and history for |
|
I've checked the changes and they look good. A couple of comments as usual :)
And one more, a bit separate:
|
|
Wojciech Kapcia wrote:
I have no idea. It was there so I assumed that it may be used by some extension so I left it as it is. Maybe it was to store info about join/left with @2@? %bmalkow - Do you have any idea why it is there?
I tested converted and worked fine, however I considered leaving it as not a good idea, as data is stored in UserRepo which will make it difficult to clean up later on. Additionally removing data from UserRepo make it possible to resume conversion if it crashes/failes as I remove data from UserRepo after proper entries in new repository are created. So restart after crash will allow to continue this operation from point where it crashed.
I agree. I deprecated few interfaces, ie. Repository to make it easier to identify and later remove. I think we should add this informations for sure.
This is starting to be an issue. We need to implement this automatic update for DB schema mechanism.
You mean description what needs to be updated between versions, etc? I agree, however having this automatic update mechanism with incremental SQL file with timestamp would make it easier and it could verify schema during startup and warn user what is missing and how to fix it.
There was simiar documentation for PubSub at wiki if I'm correct. I think it may be useful for people. But we should do this for databases and for Mongo as well. |
|
Andrzej Wójcik wrote:
Hmm, removing particular user JID (in this case
Possible solution - creating temporary user But if you confirm it works OK and there won't be data loss then we can skip it.
I've noticed that hence my comment :-)
OK, having automatic updater will be handy, but... this is separate issue - we need to transfer schema from component to main tigase server distribution packages, hence we should include it in the resulting
Something like: http://docs.tigase.org/tigase-server/snapshot/Administration_Guide/html_chunk/oldVerSchemas.html#v710notice
Yes, this is true.
Yes, this wasn't exclusive to this particular issue and component. There is a PubSubDAO description (v. https://projects.tigase.org/projects/tigase-pubsub/wiki/PubSub_DAO, a bit dated) but it doesn't cover what-is-where, and while it may be obvious, especially for us, but the question about tables pop up sometimes on the forums. At any rate - it shouldn't be included in the wiki but in the future asciidoc of the component. |
|
Wojciech Kapcia wrote:
No, no, no! Default room configuration is left in UserRepository as it fits there. If you would remove user, you would remove this configuration!
I tested converted few times and in some cases I forced it to crash. Then I restarted it and it moved rest of data without any issues. In the end all data was moved correctly.
Right
I can add following entries, but in 7.2.0 we are updating:
so there will be a lot to put in there. I would rather suggest to create asciidoc for each component and add there section "Required during update" and mention schema updates there. Then we could somehow gather this data to Tigase XMPP Server "Upgrade guide".
+1 - it should be placed in components asciidoc |
|
Andrzej Wójcik wrote:
OK, makes sense.
As mentioned before - Dan is already working on in-lining all the documentations so this should be feasible. As this is in Marking this as resolved/closed. |
|
Given that the schema is OK and the issue seems to be different I've moved the issue to separate task: #5006 |
|
Referenced from commit 8 months ago
|
Type |
New Feature
|
Priority |
Normal
|
Assignee | |
RedmineID |
3994
|
Right now MUC component uses UserRepository implementation to keep most of informations about rooms.
Due to that single room read from database results in more than one request to database.
We should create alternative MucDAO implementation which would use plain access to database to read all needed data in one request if possible.
This means we would need to create new tables, stored procedures, schema for databases, etc.