db-torque-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheldon Ross <sr...@simmgene.com>
Subject Re: Criteria needs write permissions?
Date Mon, 16 Nov 2009 22:19:03 GMT
"Second, create all criteria element using the *Peer objects.  The
DatabaseMap is populated when a *Peer class is loaded (static init).
So, all tables "Maps" you will be referencing will exist in a Database 
object keyed to the DB Schema Name."

This seems to be where I'm failing. Yes some queries will work. But I don't think
the metadata areas will work. If this is what you meant, then I apologize.

For example. Use an OrderBy clause for selecting from a database connection pool
that is not from the default schema for that object.

Connection srcConn = Torque.getConnection("nondefaultDB");
Criteria critera = new Criteria();
criteria.addAscendingOrderByColumn(TableAPeer.COLA);
TableAPeer.doSelect(criteria,srcConn);

This doesn't work for me because TableA does not exist in the dbMap
for "nondefaultDB". It does exist in the dbMap for "defaultDB" because that's
what's coded via the schema name.

SQLBuilder succeeds at building the query for 

c.add(TableAPeer.COLA, 4); 

because it doesn't reference any metadata.

It fails on the processOrderBy(db, dbMap, crit, query);
because this function assumes the metadata is there.


Ross


Greg Monroe wrote:
> Sorry for the delay, out for a long weekend (gotta stay in bed on Fri 13th!).
>
> Simple Torque Objects CAN be used with two different connection pools.  
> I have done this myself.  However, there are some special limitations. I 
> spent some time wandering the code and refreshing my memory and here's 
> what I found.
>
> First, you need to understand some definitions:
>
> Simple Torque Objects - Just the core record information methods. The methods 
> generated by the complexObjectModel build property (e.g. the ones which 
> generate the methods to get the related foreign key and children objects) 
> do not work. The autogenerated code assumes a lot about which connection
> to use.
>
> DBSchema Name - This is a string key defined via the XML schema database 
> name attribute. It is used internally by Torque to tie together all the
> schema "metadata" in a "DatabaseMap".  This is used by Torque to determine
> things like table names, column attributes, and the like.  
>
> DatabaseMap - This is the object that contains all the meta data *Map 
> objects related to a specific DBSchema name.
>
> DB Connection Pool Name - This is a string key that is defined in the 
> Torque runtime properties, e.g. the torque.dsfactory.<DB Connection Name>.*
> properties.  This is eventually stored in a Database object in the 
> TorqueInstance.
>
> Database Object - This is a container for information relating to a 
> database, e.g. the connection pool info, the dbmap, the idbroker info,
> and the like.  However, you can have a Database Object that does not
> contain all this info (e.g. a Database object with just connection 
> info).
>
> Because of historical design purposes lost in antiquity, the DB Schema
> name and the DB Connection Name tend to be considered to be the same.
> Many of the references to "DBName" are not clearly labeled as to which
> name is meant. This has lead to some poor internal coding and a lot of 
> confusion.  One of the goals of Torque 4.0 is to try to correct this.
>
> So, how do you use Simple Torque objects with multiple DBs...
>
> First, set up your connection pools in the runtime properties.  E.g.
> torque.dsfactory.databaseA.* and torque.dsfactory.databaseB.
>
> Second, create all criteria element using the *Peer objects.  The
> DatabaseMap is populated when a *Peer class is loaded (static init).
> So, all tables "Maps" you will be referencing will exist in a Database 
> object keyed to the DB Schema Name.  
>
> NOTE: The dbName parameter on the Criteria constructor refers to the
> DB Schema Name and NOT directly to a DB Connection Pool Name.  If there
> is a DB Connection Pool defined with the same name, this will be used.
>
> You need to write your code to use the methods that have a connection 
> parameter.  E.g., TablePeer.doSelect(Criteria, Connection).
>
> You get the connection object to use with this via the 
> Toque.getConnection(String name) static method.  The name here is the
> DB Connection Pool name.
>
> To tie this all together with some sample code that will move data
> from one DB to another one:
>
> Criteria c = new Criteria();  
> c.add(TableAPeer.COLA, 4);
> Connection srcConn = Torque.getConnection("databaseA");
> Connection destConn = Torque.getConnection("databaseB");
> try {
>     List results = TableAPeer.doSelect(c,srcConn);
>     Iterator rIt = results.iterator();
>     while( rIt.hasNext() ) {
>         TableA rec = (TableA) rIt.next();
>         rec.save(destConn);      
>     }
>       
> } finally {
> 	Torque.closeConnection(srcConn);
>       Torque.closeConnection(destConn);
> }
>
>
>
>   
>> -----Original Message-----
>> From: Alvaro Coronel [mailto:alvarocoronel67@yahoo.com]
>> Sent: Friday, November 13, 2009 10:50 AM
>> To: Apache Torque Users List
>> Subject: Re: Criteria needs write permissions?
>>
>> Does that mean that a Torque object can be used with two different
>> connections as long as no pool is involved?
>>
>>
>>
>> ________________________________
>> From: Thomas Vandahl <tv@apache.org>
>> To: torque-user@db.apache.org
>> Sent: Fri, November 13, 2009 1:27:26 PM
>> Subject: Re: Criteria needs write permissions?
>>
>> On 13.11.09 08:12, Thomas Fischer wrote:
>>     
>>> I'm not sure whether this is a bug or not, I need to think about it. If
>>>       
>> i
>>     
>>> remember correctly, the database name is used for the database
>>>       
>> connection
>>     
>>> (including credentials) and the table layout. Probably there are some
>>>       
>> cases
>>     
>>> where this wants to be treated differently.
>>>       
>> As I see it, the limitation is that a Torque object can only be used
>> with one database connection pool. This might or might not be considered
>> a bug, however, the given application type does not look typical to me.
>>
>> Bye, Thomas.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
>> For additional commands, e-mail: torque-user-help@db.apache.org
>>
>>
>>
>>     
> DukeCE Privacy Statement:
> Please be advised that this e-mail and any files transmitted with
> it are confidential communication or may otherwise be privileged or
> confidential and are intended solely for the individual or entity
> to whom they are addressed. If you are not the intended recipient
> you may not rely on the contents of this email or any attachments,
> and we ask that you please not read, copy or retransmit this
> communication, but reply to the sender and destroy the email, its
> contents, and all copies thereof immediately. Any unauthorized
> dissemination, distribution or copying of this communication is
> strictly prohibited.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-user-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-user-help@db.apache.org
>
>
>   

-- 
Sheldon Ross
Software Development
American Simmental Association
sross@simmgene.com
(406)587-4531 ext 102 


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


Mime
View raw message