[xwiki-devs] Fw: Re: [Issue] Commented: (XWIKI-2006) allows to configurate name of database schema [patch[
13 Jan
2008
13 Jan
'08
4:50 p.m.
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(a)gradsoft.com.ua
To: "Thomas Mortagne (JIRA)" <jira(a)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[
Hmm, on first intention coding rules are standard. Ok, I will look and
produse third patch.
***
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)
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
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
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.
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().
14 Jan
14 Jan
11:08 a.m.
Hi,
2008/1/13, rssh <rssh(a)gradsoft.com.ua>ua>:
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.
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
------- End of Forwarded Message -------
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
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(a)gradsoft.com.ua>
To: "Thomas Mortagne (JIRA)" <jira(a)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[
Hmm, on first intention coding rules are standard. Ok, I will look and
produse third patch.
***
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.
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
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
11:47 a.m.
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) 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
12:37 p.m.
2008/1/14, rssh <rssh(a)gradsoft.com.ua>ua>:
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.
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.)
table.setSchema() is never called with mysql... I will make a some
real test when I have time before continue to complain :)
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) 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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
1:19 p.m.
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:26 p.m.
On Mon, 14 Jan 2008 15:19:06 +0300, rssh wrote
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.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 :)
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:30 p.m.
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(a)gradsoft.com.ua>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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:45 p.m.
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne wrote
May be better add mysql here ? (i.e. call setSchema for any database).
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)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.
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(a)gradsoft.com.ua>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 :)
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:05 p.m.
2008/1/14, rssh <rssh(a)gradsoft.com.ua>ua>:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne
wrote
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 :)
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 ?)
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.
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(a)gradsoft.com.ua>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(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:01 p.m.
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)
3:07 p.m.
2008/1/14, rssh <rssh(a)gradsoft.com.ua>ua>:
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas Mortagne
wrote
Yes sorry setDatabase works only in virtual mode.
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)
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
3:29 p.m.
On Mon, 14 Jan 2008 15:07:11 +0100, Thomas Mortagne wrote
2008/1/14, rssh <rssh(a)gradsoft.com.ua>ua>:
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 ?
On Mon, 14 Jan 2008 14:30:30 +0100, Thomas
Mortagne wrote
Yes sorry setDatabase works only in virtual mode.
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' ?
15 Jan
15 Jan
11:14 a.m.
2008/1/14, rssh <rssh(a)gradsoft.com.ua>ua>:
On Mon, 14 Jan 2008 15:07:11 +0100, Thomas Mortagne
wrote
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.
2008/1/14, rssh <rssh(a)gradsoft.com.ua>ua>:
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 On Mon, 14 Jan 2008 14:30:30 +0100, Thomas
Mortagne wrote
Yes sorry setDatabase works only in virtual mode.
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' ?
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
11:51 a.m.
On Tue, 15 Jan 2008 11:14:26 +0100, Thomas Mortagne wrote
2008/1/14, rssh <rssh(a)gradsoft.com.ua>ua>:
On Mon, 14 Jan 2008 15:07:11 +0100, Thomas
Mortagne wrote
2008/1/14, rssh <rssh(a)gradsoft.com.ua>ua>:
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 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.
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.
2:51 p.m.
2008/1/15, Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
2008/1/14, rssh <rssh(a)gradsoft.com.ua>ua>:
Not PUBLIC but APP sorry but result is same :)
On Mon, 14 Jan 2008 15:07:11 +0100, Thomas
Mortagne wrote
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) 2008/1/14, rssh <rssh(a)gradsoft.com.ua>ua>:
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 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.
- 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.
--
Thomas Mortagne
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
16 Jan
16 Jan
1:40 a.m.
> - 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).
11:49 a.m.
2008/1/16, rssh <rssh(a)gradsoft.com.ua>ua>:
XWiki's default hsql mode which is file.
> - 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). _______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
3:31 p.m.
On Wed, 16 Jan 2008 11:49:21 +0100, Thomas Mortagne wrote
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
2008/1/16, rssh <rssh(a)gradsoft.com.ua>ua>:
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
> -
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).
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
18 Jan
18 Jan
5:14 p.m.
2008/1/16, rssh <rssh(a)gradsoft.com.ua>ua>:
On Wed, 16 Jan 2008 11:49:21 +0100, Thomas Mortagne
wrote
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 :)
2008/1/16, rssh <rssh(a)gradsoft.com.ua>ua>:
XWiki's default hsql mode which is file.
I've found the reason of failure: setDatabase was enabled only for virtual
xwiki-s > -
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).
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
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
19 Jan
19 Jan
11:54 p.m.
On Fri, 18 Jan 2008 17:14:59 +0100, Thomas Mortagne wrote
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
2008/1/16, rssh <rssh(a)gradsoft.com.ua>ua>:
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 ?
On Wed, 16 Jan 2008 11:49:21 +0100, Thomas
Mortagne wrote
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 :)
2008/1/16, rssh <rssh(a)gradsoft.com.ua>ua>:
I've found the reason of failure: setDatabase was enabled only for virtual
xwiki-s > > - 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.
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
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 Jan
20 Jan
3:56 p.m.
2008/1/19, rssh <rssh(a)gradsoft.com.ua>ua>:
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
On Fri, 18 Jan 2008 17:14:59 +0100, Thomas Mortagne
wrote
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".
2008/1/16, rssh <rssh(a)gradsoft.com.ua>ua>:
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 ? On Wed, 16 Jan 2008 11:49:21 +0100, Thomas
Mortagne wrote
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 :)
2008/1/16, rssh <rssh(a)gradsoft.com.ua>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
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs >
_______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:44 p.m.
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(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
21 Jan
21 Jan
10:33 a.m.
2008/1/20, rssh <rssh(a)gradsoft.com.ua>ua>:
You have at least initHibernate() that is called only at first request..
Yes, this sounds good to me.
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)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
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(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> >
> > --
> > Thomas Mortagne
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Ruslan Shevchenko
> GradSoft. http://www.gradsoft.ua
>
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
22 Jan
22 Jan
1:18 a.m.
> > 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(a)xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > >
> > >
> > > --
> > > Thomas Mortagne
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
> > --
> > Ruslan Shevchenko
> > GradSoft. http://www.gradsoft.ua
> >
> >
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> >
> >
>
> --
> Thomas Mortagne
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:05 p.m.
2008/1/22, rssh <rssh(a)gradsoft.com.ua>ua>:
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.
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
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(a)xwiki.org
> > > > > http://lists.xwiki.org/mailman/listinfo/devs
> > > > >
> > > >
> > > > --
> > > > Thomas Mortagne
> > > > _______________________________________________
> > > > devs mailing list
> > > > devs(a)xwiki.org
> > > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > >
> > >
> > > --
> > > Ruslan Shevchenko
> > > GradSoft. http://www.gradsoft.ua
> > >
> > >
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > >
> > >
> > >
> >
> > --
> > Thomas Mortagne
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Ruslan Shevchenko
> GradSoft. http://www.gradsoft.ua
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Ruslan Shevchenko
GradSoft. http://www.gradsoft.ua
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6082
days inactive
6091
days old
25 comments
2 participants
participants (2)
-
rssh -
Thomas Mortagne