[xwiki-devs] Fw: Re: [Issue] Commented: (XWIKI-2006) allows to configurate name of database schema [patch[
Good day, community. I think, some parts of JIRA comments (see below, especially after '***') must be discussed in mail list. ---------- Forwarded Message ----------- From: "rssh" <rssh@gradsoft.com.ua> To: "Thomas Mortagne (JIRA)" <jira@xwiki.org> Sent: Sun, 13 Jan 2008 18:45:56 +0300 Subject: Re: [Issue] Commented: (XWIKI-2006) allows to configurate name of database schema [patch[
your code does not follow the xwiki coding rules to be applied (mainly javadoc and some code style). See http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle
Hmm, on first intention coding rules are standard. Ok, I will look and produse third patch. ***
Some more personal comments: - I think you should separate theses two different features in two jira and patches - I don't see the need for staticParam(String key) and staticGetMainDatabaseSchemaName()
Ok -- what is another way to read something from configuration file in static context ? Is name of configuration file is not encapsulated inside XWiki ? - I think only HibernateStore
should knows about main database name and prefix database name, especially the way you implement it at wiki name -> database name conversion.
This means remove all you add to XWiki and call
context.getWiki().Param("xwiki.db") directly in getSchemaFromWikiName for example. - I think "xwiki.db" is not the
during initialization of wiki (where exists calls of hibernate store) context.getWiki() return null, so this is impossible.
best name for that parameter as it's only used in virtual mode and it's the main wiki database name I would prefer something like "xwiki.virtual.db.main". If this parameter means also the database name in non virtual mode I doubt it works as context's database is not taken into account in non virtual mode.
I would vote against usage of 'xwiki.virtual.db.main' in non-virtual mode, because find this confusing. (But you free to change names during/after import of the path)
About your implementation of main wiki name, I would prefer to
Sorry, I can't understand you. I does not touch implementation of main wiki name.
modify what XWikiContext.getMainWiki returns which is here for that. We could remove derby and hsqldb specifics conversions that
A afraid, that if I understand what you try to say, this will be completely other story. Much bigger and harder (and I afraid in some cases impossible). Why -- because in XWiki getDatabase()/setDatabase() calls used in meaning get/set database and get/set application name. Now, when database name and wiki name become differ, to do this would be necessary review each call of get/set Database() in XWiki and XWikiContext, understand - what was means (application name or database name) and change. This would be more complex structure (where we will have logical database names) and (from my point of view) this complexity will not give any benefits.
would be useless if it can be setted in xwiki.cfg. This means review the code to remove the remaining "xwiki" use as main wiki in place of calling context.getMainXWiki().
Sorry, but you talk about some other path. I just does not touch this part of xwiki, in my path all about 'logical names' is remaining as in previous version.
allows to configurate name of database schema [patch[ -----------------------------------------------------
Key: XWIKI-2006 URL: http://jira.xwiki.org/jira/browse/XWIKI-2006 Project: XWiki Platform Issue Type: New Feature Affects Versions: Future Environment: any Reporter: Ruslan Shevchenko Priority: Minor Attachments: configurated_db_schema_02.patch
attached path allows to configure 1. name of database schema of main wiki. 2. prefixes for database schemas for virtual wikis. (tested by hand with normal and virtual wiki configurations)
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.xwiki.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua ------- End of Forwarded Message ------- -- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
Hi, 2008/1/13, rssh <rssh@gradsoft.com.ua>:
Good day, community.
I think, some parts of JIRA comments (see below, especially after '***') must be discussed in mail list.
---------- Forwarded Message ----------- From: "rssh" <rssh@gradsoft.com.ua> To: "Thomas Mortagne (JIRA)" <jira@xwiki.org> Sent: Sun, 13 Jan 2008 18:45:56 +0300 Subject: Re: [Issue] Commented: (XWIKI-2006) allows to configurate name of database schema [patch[
your code does not follow the xwiki coding rules to be applied (mainly javadoc and some code style). See http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle
Hmm, on first intention coding rules are standard. Ok, I will look and produse third patch.
***
Some more personal comments: - I think you should separate theses two different features in two jira and patches - I don't see the need for staticParam(String key) and staticGetMainDatabaseSchemaName()
Ok -- what is another way to read something from configuration file in static context ? Is name of configuration file is not encapsulated inside XWiki ?
- I think only HibernateStore
should knows about main database name and prefix database name, especially the way you implement it at wiki name -> database name conversion.
This means remove all you add to XWiki and call
context.getWiki().Param("xwiki.db") directly in getSchemaFromWikiName for example. - I think "xwiki.db" is not the
during initialization of wiki (where exists calls of hibernate store) context.getWiki() return null, so this is impossible.
It should not be. When exactly do you have context.getWiki() null ? Maybe there is a problem in a particular case. I tested xwiki initialization and, in getSchemaFromWikiName, context's wiki is never null even the first time it's called in virtual or non virtual mode.
best name for that parameter as it's only used in virtual mode and it's the main wiki database name I would prefer something like "xwiki.virtual.db.main". If this parameter means also the database name in non virtual mode I doubt it works as context's database is not taken into account in non virtual mode.
I would vote against usage of 'xwiki.virtual.db.main' in non-virtual mode, because find this confusing.
(But you free to change names during/after import of the path)
You did not read all all I said : "If this parameter means also the database name in non virtual mode I doubt it works as context's database is not taken into account in non virtual mode." What I said is than if it works only in virtual mode I would prefer a more clear name than wiki.db and the way you did I don't see how it could work in non virtual mode. In fact it could make error with oracle databases I think because it will use the configured name for update schema and hibernate.cfg one for store and load.
About your implementation of main wiki name, I would prefer to
Sorry, I can't understand you. I does not touch implementation of main wiki name.
modify what XWikiContext.getMainWiki returns which is here for that. We could remove derby and hsqldb specifics conversions that
A afraid, that if I understand what you try to say, this will be completely other story. Much bigger and harder (and I afraid in some cases impossible). Why -- because in XWiki getDatabase()/setDatabase() calls used in meaning get/set database and get/set application name. Now, when database name and wiki name become differ, to do this would be necessary review each call of get/set Database() in XWiki and XWikiContext, understand - what was means (application name or database name) and change. This would be more complex structure (where we will have logical database names) and (from my point of view) this complexity will not give any benefits.
would be useless if it can be setted in xwiki.cfg. This means review the code to remove the remaining "xwiki" use as main wiki in place of calling context.getMainXWiki().
Sorry, but you talk about some other path. I just does not touch this part of xwiki, in my path all about 'logical names' is remaining as in previous version.
allows to configurate name of database schema [patch[ -----------------------------------------------------
Key: XWIKI-2006 URL: http://jira.xwiki.org/jira/browse/XWIKI-2006 Project: XWiki Platform Issue Type: New Feature Affects Versions: Future Environment: any Reporter: Ruslan Shevchenko Priority: Minor Attachments: configurated_db_schema_02.patch
attached path allows to configure 1. name of database schema of main wiki. 2. prefixes for database schemas for virtual wikis. (tested by hand with normal and virtual wiki configurations)
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.xwiki.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua ------- End of Forwarded Message -------
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
during initialization of wiki (where exists calls of hibernate store) context.getWiki() return null, so this is impossible.
It should not be. When exactly do you have context.getWiki() null ? Maybe there is a problem in a particular case. I tested xwiki initialization and, in getSchemaFromWikiName, context's wiki is never null even the first time it's called in virtual or non virtual mode.
Hmm, I was see ifs (on xwiki==null) and belive that this 'if' is really was needed. Now I just reread initXWiki and seen context.setWiki(this) on second line: look's like you are right. Thanks, I will retest this and return shortly.
best name for that parameter as it's only used in virtual mode and it's the main wiki database name I would prefer something like "xwiki.virtual.db.main". If this parameter means also the database name in non virtual mode I doubt it works as context's database is not taken into account in non virtual mode.
I would vote against usage of 'xwiki.virtual.db.main' in non-virtual mode, because find this confusing.
(But you free to change names during/after import of the path)
You did not read all all I said : "If this parameter means also the database name in non virtual mode I doubt it works as context's database is not taken into account in non virtual mode." What I said is than if it works only in virtual mode I would prefer a more clear name than wiki.db and the way you did I don't see how it could work in non virtual mode.
Main usage of this parameter (for me) - is non-virtual mode and Oracle. (I want to use already existent database which named other than 'xwiki'. And it's work for me.)
In fact it could make error with oracle databases I think because it will use the configured name for update schema and hibernate.cfg one for store and load.
No, it's work for me. (may be because of calls to table.setSchema() in updateSchema(), which called first) -- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
2008/1/14, rssh <rssh@gradsoft.com.ua>:
during initialization of wiki (where exists calls of hibernate store) context.getWiki() return null, so this is impossible.
It should not be. When exactly do you have context.getWiki() null ? Maybe there is a problem in a particular case. I tested xwiki initialization and, in getSchemaFromWikiName, context's wiki is never null even the first time it's called in virtual or non virtual mode.
Hmm, I was see ifs (on xwiki==null) and belive that this 'if' is really was needed. Now I just reread initXWiki and seen context.setWiki(this) on second line: look's like you are right.
Thanks, I will retest this and return shortly.
best name for that parameter as it's only used in virtual mode and it's the main wiki database name I would prefer something like "xwiki.virtual.db.main". If this parameter means also the database name in non virtual mode I doubt it works as context's database is not taken into account in non virtual mode.
I would vote against usage of 'xwiki.virtual.db.main' in non-virtual mode, because find this confusing.
(But you free to change names during/after import of the path)
You did not read all all I said : "If this parameter means also the database name in non virtual mode I doubt it works as context's database is not taken into account in non virtual mode." What I said is than if it works only in virtual mode I would prefer a more clear name than wiki.db and the way you did I don't see how it could work in non virtual mode.
Main usage of this parameter (for me) - is non-virtual mode and Oracle. (I want to use already existent database which named other than 'xwiki'. And it's work for me.)
In fact it could make error with oracle databases I think because it will use the configured name for update schema and hibernate.cfg one for store and load.
No, it's work for me. (may be because of calls to table.setSchema() in updateSchema(), which called first)
table.setSchema() is never called with mysql... I will make a some real test when I have time before continue to complain :)
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
No, it's work for me. (may be because of calls to table.setSchema() in updateSchema(), which called first)
table.setSchema() is never called with mysql... I will make a some real test when I have time before continue to complain :)
May be better add mysql here ? (i.e. call setSchema for any database).
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
On Mon, 14 Jan 2008 15:19:06 +0300, rssh wrote
No, it's work for me. (may be because of calls to table.setSchema() in updateSchema(), which called first)
table.setSchema() is never called with mysql... I will make a some real test when I have time before continue to complain :)
May be better add mysql here ? (i.e. call setSchema for any database).
I just submitted next version of path, without touching updateSchema for mysql. (I think this must be another (may be next) issue)
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
No as the goal of this code is not to chose the database/schema where to works, it set the schema name to use when generating the update script for database engines based on schemas. MySQL does not need it because MySQL is based on databases. The only place where database/schema is really changed is setDatabase() and only in non virtual mode as far as I know. 2008/1/14, rssh <rssh@gradsoft.com.ua>:
No, it's work for me. (may be because of calls to table.setSchema() in updateSchema(), which called first)
table.setSchema() is never called with mysql... I will make a some real test when I have time before continue to complain :)
May be better add mysql here ? (i.e. call setSchema for any database).
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne wrote
No as the goal of this code is not to chose the database/schema where to works, it set the schema name to use when generating the update script for database engines based on schemas. MySQL does not need it because MySQL is based on databases.
What means 'based on schema/based on database' ? I. e. what is the difference from the API point of view ? (Or this difference is hided by hibernate ?)
The only place where database/schema is really changed is setDatabase() and only in non virtual mode as far as I know.
You again talk about 'logical' layer. Idea is do not touch 'logical layer' at all, instead touch hibernate configuration. As I understand, table.setScheme() do this for 'scheme-based' databases (?) And must exist some other way for mysql [?] (so, I go to read hibernate docs).
2008/1/14, rssh <rssh@gradsoft.com.ua>:
No, it's work for me. (may be because of calls to table.setSchema() in updateSchema(), which called first)
table.setSchema() is never called with mysql... I will make a some real test when I have time before continue to complain :)
May be better add mysql here ? (i.e. call setSchema for any database).
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
2008/1/14, rssh <rssh@gradsoft.com.ua>:
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne wrote
No as the goal of this code is not to chose the database/schema where to works, it set the schema name to use when generating the update script for database engines based on schemas. MySQL does not need it because MySQL is based on databases.
What means 'based on schema/based on database' ?
The good example is Postgre : you have database containing shemas containing tables. If I understood well (it's pretty new for me that there is a difference between databases and schemas) database are "physical" object when schemas are just something like tables prefix and maybe a little more depends of the database engine. For example in Derby there is no way to list them. MySQL only manage database and HSQL and derby only manage schemas. At hibernate level the difference is at what hibernate call "catalog" which is implemented by mysql driver with database. But HSQLDB and derby (and Oracle too it seems) for example does not implement it. When you look in setDatabase() you can see that by default setCatalog is used but only MySQL support it. As I said this is new for me and I can make dome mistake :)
I. e. what is the difference from the API point of view ? (Or this difference is hided by hibernate ?)
The only place where database/schema is really changed is setDatabase() and only in non virtual mode as far as I know.
You again talk about 'logical' layer.
Idea is do not touch 'logical layer' at all, instead touch hibernate configuration.
As I understand, table.setScheme() do this for 'scheme-based' databases (?) And must exist some other way for mysql [?] (so, I go to read hibernate docs).
I'm not sure it's really change the current schema for shema-based databases, I'm just sure this code is not executed with MySQL.
2008/1/14, rssh <rssh@gradsoft.com.ua>:
No, it's work for me. (may be because of calls to table.setSchema() in updateSchema(), which called first)
table.setSchema() is never called with mysql... I will make a some real test when I have time before continue to complain :)
May be better add mysql here ? (i.e. call setSchema for any database).
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne wrote
No as the goal of this code is not to chose the database/schema where to works, it set the schema name to use when generating the update script for database engines based on schemas. MySQL does not need it because MySQL is based on databases.
The only place where database/schema is really changed is setDatabase() and only in non virtual mode as far as I know.
May be you mean 'only in virtual mode' ? If so, I understood (and we just don't need such parameter for mysql, becouse in non-virtual mode database is passed in jdbc URL)
2008/1/14, rssh <rssh@gradsoft.com.ua>:
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne wrote
No as the goal of this code is not to chose the database/schema where to works, it set the schema name to use when generating the update script for database engines based on schemas. MySQL does not need it because MySQL is based on databases.
The only place where database/schema is really changed is setDatabase() and only in non virtual mode as far as I know.
May be you mean 'only in virtual mode' ?
Yes sorry setDatabase works only in virtual mode.
If so, I understood (and we just don't need such parameter for mysql, becouse in non-virtual mode database is passed in jdbc URL)
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Mon, 14 Jan 2008 15:07:11 +0100, Thomas Mortagne wrote
2008/1/14, rssh <rssh@gradsoft.com.ua>:
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne wrote
No as the goal of this code is not to chose the database/schema where to works, it set the schema name to use when generating the update script for database engines based on schemas. MySQL does not need it because MySQL is based on databases.
The only place where database/schema is really changed is setDatabase() and only in non virtual mode as far as I know.
May be you mean 'only in virtual mode' ?
Yes sorry setDatabase works only in virtual mode.
Or, in such case we have: scheme-based, non-virtual mode: patch do all work correctly. (ok) scheme-based, virtual mode: patch do all work correctly. (ok) database-based, non-virtual mode: path does not touch nothing (ok, I think) database-based, virtual mode: see below: (problem) path does not touch nothing for main database, but touch virtual databases, except case, when we call setDatabase() for main database So, in XWikiHibernateBaseStore.setDatabase() for mysql we need check, that this is main database and for main database does not call getSchemaForWikiName() Is this way looks acceptable ?
2008/1/14, rssh <rssh@gradsoft.com.ua>:
On Mon, 14 Jan 2008 15:07:11 +0100, Thomas Mortagne wrote
2008/1/14, rssh <rssh@gradsoft.com.ua>:
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne wrote
No as the goal of this code is not to chose the database/schema where to works, it set the schema name to use when generating the update script for database engines based on schemas. MySQL does not need it because MySQL is based on databases.
The only place where database/schema is really changed is setDatabase() and only in non virtual mode as far as I know.
May be you mean 'only in virtual mode' ?
Yes sorry setDatabase works only in virtual mode.
Or, in such case we have:
scheme-based, non-virtual mode: patch do all work correctly. (ok) scheme-based, virtual mode: patch do all work correctly. (ok) database-based, non-virtual mode: path does not touch nothing (ok, I think) database-based, virtual mode: see below: (problem) path does not touch nothing for main database, but touch virtual databases, except case, when we call setDatabase() for main database
I tested your patch (at last) with "xwiki.db=toto" and "xwiki.virtual.db.prefix=prefix" and my results are : - mysql - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : do noting (useless) - hsqldb : - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok) - derby : - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok) - postgre : - non-virtual : do nothing (useless) - virtual : not implemented To summarize : this patch does not works with hsqldb and derby and only work in virtual mode. As I said before "table.setSchema" does not change default schema it only set schema to use in update script.
So, in XWikiHibernateBaseStore.setDatabase() for mysql we need check, that this is main database and for main database does not call getSchemaForWikiName()
Is this way looks acceptable ?
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Tue, 15 Jan 2008 11:14:26 +0100, Thomas Mortagne wrote
2008/1/14, rssh <rssh@gradsoft.com.ua>:
On Mon, 14 Jan 2008 15:07:11 +0100, Thomas Mortagne wrote
2008/1/14, rssh <rssh@gradsoft.com.ua>:
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne wrote
No as the goal of this code is not to chose the database/schema where to works, it set the schema name to use when generating the update script for database engines based on schemas. MySQL does not need it because MySQL is based on databases.
The only place where database/schema is really changed is setDatabase() and only in non virtual mode as far as I know.
May be you mean 'only in virtual mode' ?
Yes sorry setDatabase works only in virtual mode.
Or, in such case we have:
scheme-based, non-virtual mode: patch do all work correctly. (ok) scheme-based, virtual mode: patch do all work correctly. (ok) database-based, non-virtual mode: path does not touch nothing (ok, I think) database-based, virtual mode: see below: (problem) path does not touch nothing for main database, but touch virtual databases, except case, when we call setDatabase() for main database
I tested your patch (at last) with "xwiki.db=toto" and "xwiki.virtual.db.prefix=prefix" and my results are : - mysql - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : do noting (useless) - hsqldb : - virtual : change main wiki database name and correctly apply prefix (could be usefull)
- non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok) - non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok)
Thanks ! I will try to reproduce results and do something with this.
- postgre : - non-virtual : do nothing (useless) - virtual : not implemented
To summarize : this patch does not works with hsqldb and derby and only work in virtual mode. As I said before "table.setSchema" does
It works for me for oracle in non-virtual mode. (I actually wrote it (and use now) for oracle in non-virtual mode).
not change default schema it only set schema to use in update script.
2008/1/15, Thomas Mortagne <thomas.mortagne@xwiki.com>:
2008/1/14, rssh <rssh@gradsoft.com.ua>:
On Mon, 14 Jan 2008 15:07:11 +0100, Thomas Mortagne wrote
2008/1/14, rssh <rssh@gradsoft.com.ua>:
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne wrote
No as the goal of this code is not to chose the database/schema where to works, it set the schema name to use when generating the update script for database engines based on schemas. MySQL does not need it because MySQL is based on databases.
The only place where database/schema is really changed is setDatabase() and only in non virtual mode as far as I know.
May be you mean 'only in virtual mode' ?
Yes sorry setDatabase works only in virtual mode.
Or, in such case we have:
scheme-based, non-virtual mode: patch do all work correctly. (ok) scheme-based, virtual mode: patch do all work correctly. (ok) database-based, non-virtual mode: path does not touch nothing (ok, I think) database-based, virtual mode: see below: (problem) path does not touch nothing for main database, but touch virtual databases, except case, when we call setDatabase() for main database
I tested your patch (at last) with "xwiki.db=toto" and "xwiki.virtual.db.prefix=prefix" and my results are : - mysql - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : do noting (useless) - hsqldb : - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok) - derby : - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok)
Not PUBLIC but APP sorry but result is same :)
- postgre : - non-virtual : do nothing (useless) - virtual : not implemented
To summarize : this patch does not works with hsqldb and derby and only work in virtual mode. As I said before "table.setSchema" does not change default schema it only set schema to use in update script.
So, in XWikiHibernateBaseStore.setDatabase() for mysql we need check, that this is main database and for main database does not call getSchemaForWikiName()
Is this way looks acceptable ?
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
-- Thomas Mortagne
- hsqldb : - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok)
Are you running hsql in file or server mode ? (I try to reproduce error).
2008/1/16, rssh <rssh@gradsoft.com.ua>:
- hsqldb : - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok)
Are you running hsql in file or server mode ? (I try to reproduce error).
XWiki's default hsql mode which is file.
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Wed, 16 Jan 2008 11:49:21 +0100, Thomas Mortagne wrote
2008/1/16, rssh <rssh@gradsoft.com.ua>:
- hsqldb : - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok)
Are you running hsql in file or server mode ? (I try to reproduce error).
XWiki's default hsql mode which is file.
I've found the reason of failure: setDatabase was enabled only for virtual xwiki-s patch is attached (tested with hsql in non-virtual mode in addition to oracle in virtual/unvirtual). I will attach one to jira thought few seconds. P.S. also note, that exitsts hibernate property 'default_schema' which (when we change name) must not conflict with xwiki.db
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
2008/1/16, rssh <rssh@gradsoft.com.ua>:
On Wed, 16 Jan 2008 11:49:21 +0100, Thomas Mortagne wrote
2008/1/16, rssh <rssh@gradsoft.com.ua>:
- hsqldb : - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok)
Are you running hsql in file or server mode ? (I try to reproduce error).
XWiki's default hsql mode which is file.
I've found the reason of failure: setDatabase was enabled only for virtual xwiki-s
Yes and just enable it in non-virtual mode will create lots of problems because if you do that you don't have non-virtual mode anymore :)
patch is attached (tested with hsql in non-virtual mode in addition to oracle in virtual/unvirtual). I will attach one to jira thought few seconds.
P.S. also note, that exitsts hibernate property 'default_schema' which (when we change name) must not conflict with xwiki.db
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Fri, 18 Jan 2008 17:14:59 +0100, Thomas Mortagne wrote
2008/1/16, rssh <rssh@gradsoft.com.ua>:
On Wed, 16 Jan 2008 11:49:21 +0100, Thomas Mortagne wrote
2008/1/16, rssh <rssh@gradsoft.com.ua>:
- hsqldb : - virtual : change main wiki database name and correctly apply prefix (could be usefull) - non-virtual : updateSchipt is done in toto and retrieve/save document in PUBLIC (not ok)
Are you running hsql in file or server mode ? (I try to reproduce error).
XWiki's default hsql mode which is file.
I've found the reason of failure: setDatabase was enabled only for virtual xwiki-s
Yes and just enable it in non-virtual mode will create lots of problems because if you do that you don't have non-virtual mode anymore :)
Ohh - let's I try to understand the situation without vicious circle in definitions. Virtual mode - across all code we determinate, that we in virtual mode by isVirtual() (which return us parameter xwiki.virtual). setDatabase() can't change value of parameter 'xwiki.virtual', so: we can't say that we have non-virtual mode. 1. Are exists any concrete problems, which we can describe without references to 'virtual/non-virtual' models ? 2. I see, the maximum problem, what we can have -- is loading/store of scheme without previous call of setDatabase(). Are this problem really exists and where ?
patch is attached (tested with hsql in non-virtual mode in addition to oracle in virtual/unvirtual). I will attach one to jira thought few seconds.
P.S. also note, that exitsts hibernate property 'default_schema' which (when we change name) must not conflict with xwiki.db
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
2008/1/19, rssh <rssh@gradsoft.com.ua>:
On Fri, 18 Jan 2008 17:14:59 +0100, Thomas Mortagne wrote
2008/1/16, rssh <rssh@gradsoft.com.ua>:
On Wed, 16 Jan 2008 11:49:21 +0100, Thomas Mortagne wrote
2008/1/16, rssh <rssh@gradsoft.com.ua>:
> - hsqldb : > - virtual : change main wiki database name and correctly apply > prefix (could be usefull) > - non-virtual : updateSchipt is done in toto and retrieve/save > document in PUBLIC (not ok)
Are you running hsql in file or server mode ? (I try to reproduce error).
XWiki's default hsql mode which is file.
I've found the reason of failure: setDatabase was enabled only for virtual xwiki-s
Yes and just enable it in non-virtual mode will create lots of problems because if you do that you don't have non-virtual mode anymore :)
Ohh - let's I try to understand the situation without vicious circle in definitions.
Virtual mode - across all code we determinate, that we in virtual mode by isVirtual() (which return us parameter xwiki.virtual). setDatabase() can't change value of parameter 'xwiki.virtual', so: we can't say that we have non-virtual mode.
1. Are exists any concrete problems, which we can describe without references to 'virtual/non-virtual' models ? 2. I see, the maximum problem, what we can have -- is loading/store of scheme without previous call of setDatabase(). Are this problem really exists and where ?
isVirtual is just an information XWiki use to know if it's in virtual mode or not. If you allow setDatabase in non-virtual mode you will be "physically" in virtual mode. That means you can access any wiki in the same database just using context.setDatabase from Velocity. It's a big difference at least for security when you have more than one XE in the same database. Another thing is that setDatabase is called for each query and execute "SET SCHEMA" or anything else depends of database type and it will double queries in non-virtual mode to always switch from wiki "wikiname" to "wikiname". There is others ways to do what you want like calling setDatabase with a parameter "force" at database init for example only if "wiki.db" is set. I don't say virtual/non-virtual separation can't be removed but it's another subject and imply more than just "allows to configurate name of database schema".
patch is attached (tested with hsql in non-virtual mode in addition to oracle in virtual/unvirtual). I will attach one to jira thought few seconds.
P.S. also note, that exitsts hibernate property 'default_schema' which (when we change name) must not conflict with xwiki.db
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
isVirtual is just an information XWiki use to know if it's in virtual mode or not. If you allow setDatabase in non-virtual mode you will be "physically" in virtual mode. That means you can access any wiki in the same database just using context.setDatabase from Velocity. It's a big difference at least for security when you have more than one XE in the same database. Another thing is that setDatabase is called
understand. [A]
for each query and execute "SET SCHEMA" or anything else depends of database type and it will double queries in non-virtual mode to always switch from wiki "wikiname" to "wikiname".
If we does not call setScheme, that hibernate do this (for scheme-based databases) during each initialization of XWiki, which we usually have on each web request. So, I does not guess big difference in performance. [B]
There is others ways to do what you want like calling setDatabase with a parameter "force" at database init for example only if "wiki.db" is set.
Ok, I will look. Is the next strategy will be accessible (?) : 1. add to xwiki boolean member variable, which means, that 'database does not yet initialized'. 2. enable setDatabase in non-virtyal mode only if we does not call yet 'setDatabase' for this xwiki instance. This will fix security issue 'A' and partially - reduce extra overhead in 'B'. So, is this plan looks normal ?
I don't say virtual/non-virtual separation can't be removed but it's another subject and imply more than just "allows to configurate name of database schema".
patch is attached (tested with hsql in non-virtual mode in addition
to oracle
in virtual/unvirtual). I will attach one to jira thought few seconds.
P.S. also note, that exitsts hibernate property 'default_schema' which (when we change name) must not conflict with xwiki.db
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
2008/1/20, rssh <rssh@gradsoft.com.ua>:
isVirtual is just an information XWiki use to know if it's in virtual mode or not. If you allow setDatabase in non-virtual mode you will be "physically" in virtual mode. That means you can access any wiki in the same database just using context.setDatabase from Velocity. It's a big difference at least for security when you have more than one XE in the same database. Another thing is that setDatabase is called
understand. [A]
for each query and execute "SET SCHEMA" or anything else depends of database type and it will double queries in non-virtual mode to always switch from wiki "wikiname" to "wikiname".
If we does not call setScheme, that hibernate do this (for scheme-based databases) during each initialization of XWiki, which we usually have on each web request. So, I does not guess big difference in performance. [B]
You have at least initHibernate() that is called only at first request..
There is others ways to do what you want like calling setDatabase with a parameter "force" at database init for example only if "wiki.db" is set.
Ok, I will look.
Is the next strategy will be accessible (?) :
1. add to xwiki boolean member variable, which means, that 'database does not yet initialized'. 2. enable setDatabase in non-virtyal mode only if we does not call yet 'setDatabase' for this xwiki instance.
This will fix security issue 'A' and partially - reduce extra overhead in 'B'.
So, is this plan looks normal ?
Yes, this sounds good to me.
I don't say virtual/non-virtual separation can't be removed but it's another subject and imply more than just "allows to configurate name of database schema".
patch is attached (tested with hsql in non-virtual mode in addition
to oracle
in virtual/unvirtual). I will attach one to jira thought few seconds.
P.S. also note, that exitsts hibernate property 'default_schema' which (when we change name) must not conflict with xwiki.db
> _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
When you will have a nice implementation that works on all databases, this feature will need a vote I think as it touch a very important part of XWiki engine. -- Thomas Mortagne
There is others ways to do what you want like calling setDatabase with a parameter "force" at database init for example only if "wiki.db" is set.
Ok, I will look.
From reading source code: situation is more interesting, that I was think before. Why: We need call setDatabase() not once per xwiki, but once per new hibernate session. But sessions are controlled by hibernate, not by us. Typical solution in such situation (near any middleware has something simular) is to keep own weak map of sessions, and if database was not set for this session -- set one. I see exists commented out 'ConcurrentHashMap' of connections (for monitoring) which can server this purpose - but non-weak HashMap without nurse process can cause memory leaks. (it's why one commented) So, my original plan now looks like incorrect, instead we must choose one from three possible solutions: 1) [I guess best in short-term perspective] Force setDatabase() in beginTransaction() only. This will solve all security problems and partially - overhead. But we will have non-empty overhead for non-virtual mode and non-empty xwiki.db, becouse once-per-transaction is worse then once-per-session (but better than onec-per-operation). Since this overhead will take place only when we set xwiki.db, I think that this is acceptable and will submit appropriative patch. (in case of absence of abjections). 2) Restore map of connections, but not as ConcurrentHashMap, but as WeakHashMap with lock. This will restore functionality for monitoring, but add overhead (I think small, but who know about large-scale installations) for serializing sessions access. 3) In reality we need data structure, something like ConcurrentWeakHashMap. [JBoss Remoting hase one]. We can get one from JBoss, but it's possible to write one from scratch (and may be safer for license issues). I think this is the best way in long-term perspective, but will require some additional work. So, I want now do [1] and may be think about [3] in future, but without any estimations of time.
Is the next strategy will be accessible (?) :
1. add to xwiki boolean member variable, which means, that 'database does not yet initialized'. 2. enable setDatabase in non-virtyal mode only if we does not call yet 'setDatabase' for this xwiki instance.
This will fix security issue 'A' and partially - reduce extra overhead in 'B'.
So, is this plan looks normal ?
Yes, this sounds good to me.
I don't say virtual/non-virtual separation can't be removed but it's another subject and imply more than just "allows to configurate name of database schema".
patch is attached (tested with hsql in non-virtual mode in addition
to oracle
in virtual/unvirtual). I will attach one to jira thought few seconds.
P.S. also note, that exitsts hibernate property 'default_schema' which (when we change name) must not conflict with xwiki.db
> > _______________________________________________ > > devs mailing list > > devs@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
When you will have a nice implementation that works on all databases, this feature will need a vote I think as it touch a very important part of XWiki engine.
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
2008/1/22, rssh <rssh@gradsoft.com.ua>:
There is others ways to do what you want like calling setDatabase with a parameter "force" at database init for example only if "wiki.db" is set.
Ok, I will look.
From reading source code: situation is more interesting, that I was think before. Why: We need call setDatabase() not once per xwiki, but once per new hibernate session. But sessions are controlled by hibernate, not by us. Typical solution in such situation (near any middleware has something simular) is to keep own weak map of sessions, and if database was not set for this session -- set one.
I see exists commented out 'ConcurrentHashMap' of connections (for monitoring) which can server this purpose - but non-weak HashMap without nurse process can cause memory leaks. (it's why one commented)
So, my original plan now looks like incorrect, instead we must choose one from three possible solutions:
1) [I guess best in short-term perspective] Force setDatabase() in beginTransaction() only. This will solve all security problems and partially - overhead. But we will have non-empty overhead for non-virtual mode and non-empty xwiki.db, becouse once-per-transaction is worse then once-per-session (but better than onec-per-operation). Since this overhead will take place only when we set xwiki.db, I think that this is acceptable and will submit appropriative patch. (in case of absence of abjections).
2) Restore map of connections, but not as ConcurrentHashMap, but as WeakHashMap with lock. This will restore functionality for monitoring, but add overhead (I think small, but who know about large-scale installations) for serializing sessions access.
3) In reality we need data structure, something like ConcurrentWeakHashMap. [JBoss Remoting hase one]. We can get one from JBoss, but it's possible to write one from scratch (and may be safer for license issues). I think this is the best way in long-term perspective, but will require some additional work.
So, I want now do [1] and may be think about [3] in future, but without any estimations of time.
I don't know hibernate enough at this time to be able to seriously comment your proposals [2] et [3]. About [1], as it not worst than virtual mode I think it could be acceptable if there is no other ways to do that.
Is the next strategy will be accessible (?) :
1. add to xwiki boolean member variable, which means, that 'database does not yet initialized'. 2. enable setDatabase in non-virtyal mode only if we does not call yet 'setDatabase' for this xwiki instance.
This will fix security issue 'A' and partially - reduce extra overhead in 'B'.
So, is this plan looks normal ?
Yes, this sounds good to me.
I don't say virtual/non-virtual separation can't be removed but it's another subject and imply more than just "allows to configurate name of database schema".
> > patch is attached (tested with hsql in non-virtual mode in addition
to oracle
> in virtual/unvirtual). I will attach one to jira thought few seconds. > > P.S. also note, that exitsts hibernate property 'default_schema' which (when > we change name) must not conflict with xwiki.db > > > > > _______________________________________________ > > > devs mailing list > > > devs@xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > -- > > Thomas Mortagne > > _______________________________________________ > > devs mailing list > > devs@xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Ruslan Shevchenko > GradSoft. http://www.gradsoft.ua > > > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs > > >
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
When you will have a nice implementation that works on all databases, this feature will need a vote I think as it touch a very important part of XWiki engine.
-- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Ruslan Shevchenko GradSoft. http://www.gradsoft.ua
_______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
participants (2)
-
rssh -
Thomas Mortagne