Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
To: torque-dev@db.apache.org
Path: not-for-mail
From: "Henning P. Schmiedehausen" <hps@intermeta.de>
Newsgroups: hometree.jakarta.torque.dev
Subject: Re: provide a central place for parsing column names in SQLBuilder
Date: Mon, 13 Dec 2004 22:02:45 +0000 (UTC)
Organization: INTERMETA - Gesellschaft fuer Mehrwertdienste mbH
Lines: 131
Message-ID: <cpl3i5$28b$1@tangens.hometree.net>
References: <cpkiqp$ofq$1@tangens.hometree.net>
 <OFE7888D3B.D1D47EB7-ONC1256F69.0060F71B-C1256F69.0066E8C3@seitenbau.net>
Reply-To: hps@intermeta.de
NNTP-Posting-Host: forge.intermeta.de
NNTP-Posting-Date: Mon, 13 Dec 2004 22:02:45 +0000 (UTC)
User-Agent: nn/6.6.5

Thomas Fischer <Fischer@seitenbau.net> writes:

>Henning,

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

Nice. I expect this to fail on DBs which don't support schemas like
MySQL (?) (my MySQL is a bit rusty, 3.x didn't have them).

>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

Yep, that was a nice side effect.

>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.)

There is a lot of work to be done. The parsing of the column names is
shady at best. However, it does work and does not break the current state
which is important IMHO.

>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

It is in the DatasourceFactories. Torque is just the static facade. I'm
open to better ideas.

>default schema for each database user, so what harm ist there to have a
>default schema per database in torque ?

Some DBs will choke on the schema, I'm sure. I was concerned about
backwards compatibility. So if you don't set the schema, it will not
be visible.

>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).

Yes. As I said, I didn't check in the whole patch. Internally for us
here, schemaName is a part of the Criteria and the Torque.getSchema()
is just the fallback. However, this brings _massive_ changes in the
generator, the internal structure of the runtime and everything else
(up to the method signatures for Criteria. Not 3.1 material at all).
We e.g. have a bean called TableType which is a
dbName/schemaName/tableName triple and controls the column name
generation.

>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.

No. Testers welcome.

>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.

Definitely!

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

RedHat Certified Engineer -- Jakarta Turbine Development  -- hero for hire
   Linux, Java, perl, Solaris -- Consulting, Training, Development

What is more important to you...
   [ ] Product Security
or [ ] Quality of Sales and Marketing Support
              -- actual question from a Microsoft customer survey

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