Mailing-List: contact torque-user-help@db.apache.org; run by ezmlm
User-Agent: Microsoft-Entourage/10.1.1.2418
Date: Fri, 07 Feb 2003 10:56:51 +1100
Subject: Re: Attn: PostgreSQL users
From: Scott Eade <seade@backstagetech.com.au>
To: Torque Users List <torque-user@db.apache.org>
Message-ID: <BA694173.F84B%seade@backstagetech.com.au>
In-Reply-To: <3E42E1EB.9080406@redsheriff.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit

I am wondering if it is a generation time vs. a runtime thing.  What is
DATABASE_NAME initialised to in the generated Base*Peer classes?

The runtime Torque.properties can be configured to handle multiple
databases.  You configure a dsfactory for each database and map a physical
database to the logical database name that is used internally by torque.
The torque.database.default property is used to configure which dsfactory
should be used when one is not provided to a query (although I suspect
torque is really using the DATABASE_NAME property generated into the
Base*Peer class).

HTH,

Scott
-- 
Scott Eade
Backstage Technologies Pty. Ltd.
http://www.backstagetech.com.au
.Mac Chat/AIM: seade at mac dot com


On 7/02/2003 9:30 AM, "CP Lim" <cp_lim@redsheriff.com> wrote:

> Hi Scott,
> 
> Been using postgreSQL and Torque (v3.0) for a while now and was reading
> through your FAQ and looking at the section on using "native"
> (sequences) jogged my memory on my Torque.properties file.
> 
> My Torque settings are is as follows:
> 
> -------------------------------------
> torque.database.default=drop4
> torque.database.default.adapter=postgresql #its using 'default' as name
> -------------------------------------
> 
> which has a different _property name_ from the default setting supplied
> by the newapp application:
> 
> -------------------------------------
> torque.database.default=newapp
> torque.database.newapp.adapter=postgresql # using 'newapp' as name
> -------------------------------------
> 
> If I changed my settings to mirror that of newapp's, ie.
> 
> -------------------------------------
> torque.database.default=drop4
> torque.database.drop4.adapter=postgresql
> -------------------------------------
> 
> I can no longer insert into the table and the following exception is thrown
> -------------------------------------
> Caused by: org.apache.torque.TorqueException: IdGenerator for table
> 'rs_user' is null
> at org.apache.torque.util.BasePeer.doInsert(BasePeer.java:690)
> at 
> com.redsheriff.core.torque.BaseRsUserPeer.doInsert(BaseRsUserPeer.java:267)
> at 
> com.redsheriff.core.torque.BaseRsUserPeer.doInsert(BaseRsUserPeer.java:652)
> at com.redsheriff.core.torque.BaseRsUser.save(BaseRsUser.java:1039)
> at com.redsheriff.admeasure.core.AMUserMgr.save(AMUserMgr.java:371)
> -------------------------------------
> 
> I've debugged through the Torque v3.0 source and it looks like in the
> BasePeer.doInsert(Criteria, Connection) method,  the IdGenerator object
> returned (line 674) is null.  Examining this further it turns out that
> the DatabaseMap object does in fact contain a reference to the native
> IdGenerator, but is mapped to the name 'drop4'.  So when its configured
> as above (I think) its using 'default' as the key so null (IdGenerator)
> is returned.
> 
> My question is: Is this a bug or have I misunderstood the
> Torque.properties configuration file?
> 
> (Sorry about the long winded email, but had to illustrate what I was
> experiencing).
> 
> cheers,
> CP
> 
> 
> Scott Eade wrote:
>> I am toying with the idea of switching from MySQL to PostgreSQL and so I am
>> looking through all of the problems people seem to be having.  I have
>> summarised my findings so far on the wiki:
>> 
>> http://nagoya.apache.org/wiki/apachewiki.cgi?TorqueProjectPages/PostgreSQLFA
>> Q
>> 
>> If the existing PostgreSQL users can add to this page it would he helpful
>> not only to me, but also to everyone else that is either currently using or
>> considering using PostgreSQL.
>> 
>> I will commit the four noted issues, as long as I can get confirmation that
>> they are necessary (and after I am able to access the new db-torque cvs
>> module).
>> 
>> If we can flesh the other points out we should be able to integrate the
>> result back into the postgresql-howto.
>> 
>> Note that as things currently stand I don't think I am going to have the
>> time necessary to actually switch to PostgreSQL, but most of the highlighted
>> issues seem fairly close to resolution so we may as well attack them.
>> 
>> Cheers,
>> 
>> Scott
>