db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fischer <Fisc...@seitenbau.net>
Subject Re: provide a central place for parsing column names in SQLBuilder
Date Mon, 13 Dec 2004 18:44:01 GMT




Henning,

I just checked out your changes and they pass the runtime test on Oracle
9.2 ;-)

I am also very glad that all the initialisation procedures in the DB
adapters have been simplified, and that the parsing of the tablenames now
happens at a central place (though there are still a lot of methods for
this, but this is certainly to be blamed on me, not you. Perhaps I can
remedy this at some point.)

I felt a bit uneasy about putting default schema suppurt directly into the
Torque object at my first impression. But then, e.g. in Oracle there is a
default schema for each database user, so what harm ist there to have a
default schema per database in torque ?
As for dynamically changing the schema name, well, if you need it... I am
glad that I don't (Torque is a Singleton, so if you change it at one place,
it gets changed in all the other places without warning. Even the thought
makes me shudder).

Just out of curiosity : have you tried what happens if one puts
"schemaname.tablename" as tablename into schema.xml ? That might also be
interesting for some people.

More comments below

"Henning P. Schmiedehausen" <hps@intermeta.de> schrieb am 13.12.2004
18:17:13:

> I just forced my Schema patch onto an unsuspecting public. :-)
>
> Please review; this patch does what I need for Torque which might not
> exactly be what everyone wants.
>
> In a nutshell: I have an application that uses a database schema for
> storing application state. Now this application is required to be
> multi-state. For convenience, we just use multiple schemas with the
> same table structure and let the user select the schema for the
> required application state.
>
> This is less than perfect, because one datasource currently cannot
> access different schemas (e.g. for different users).

I am not sure what you want to do here. I thought that with your patch, one
can either add the Schema name to the tablename when doing a select and
then have full control over what schema to use with what table, or one can
use the defaults. This makes perfect sense for me. What more could one want
? Ok, it would be nice if I could thell the Criteria object "use this
schema for this table/alias, and another schema for another", but this can
be added later.

> However, without
> any per-database-session state object around in Torque, this is
> currently pretty hard to do (that is the part that I did _not_ check
> into the CVS...)

I do not know about hibernate sessions, but assigning a schema to e.g. a
connection would not make sense to me. For me, the location of tables is
rather static, and only in extraordinary circumstances should be changed on
runtime. In my example above, assigning a schema to a criteria would still
be a per-criteria operation, and this is the scope which would make sense
for me. Nearly everything (except transactions) in Torque is done on a
per-Criteria-Basis, which I do not consider a disadvantage. If somebody has
several criteria presets, he/she can build a factory for it, no need to
store them in a session.

I am under the slight impression that I did not grab what you meant,
though.

>
> The fact that there is no "state" object like e.g. the Hibernate
> Session object really starts to hurt here...

>
> Please test. This passes the unit and runtime tests with PostgreSQL
> but I'm very keen on hearing other success / failure stories.
>

Do you think that it makes sense to create runtime testcases for the
extended functionality ? I am not sure whether every database supports
schemata, but it would certainly help to have some testcases ready, even if
one has to enable them by hand in some way.

>    Regards
>       Henning

Thomas


---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org


Mime
View raw message