> Ok, I apologize for the traffic.
No reason to apologize for anything. This is a perfectly valid question.
> Here goes, when you build the database objects, it hardcodes in the
> database name that exists in your schema.xml. The code is in the
> doBuild() method of the ${Table}MapBuild.java
>
>
"So, people get confused when it seems like you can't use the DB objects
with more than one database connection. But that's not true. To use
more than one connection pool, you need to use the methods that take a
connection object."
In this case the query still fails even if you specify the conn
OK, I think I understand what's going on here. It's really a semi-bug
part but part a definitional issue. This is because the term database
name/dbname actually has two meaning in Torque.
The first is the "schema database name", i.e. the name in your schema
XML. This is used to group all th
Ok, I apologize for the traffic.
Here goes, when you build the database objects, it hardcodes in the
database name that exists in your schema.xml. The code is in the
doBuild() method of the ${Table}MapBuild.java
public void doBuild() throws TorqueException
{
dbMap = Torque.getDatab
Ok, I think this maybe a bug. After watching the addTable method in
DatabaseMap, It appears to add the table to the default database dbMap
even if the criteria is querying against a different database.
Sheldon Ross wrote:
That would probably work, but It seems a little overkill. Do you know
w
That would probably work, but It seems a little overkill. Do you know
where the lazy loading happens?
When I run with r/w connection, the dbmap tables hash does appear to
load that way.
However when I run the readonly connection, it just stays empty.
Thanks
Greg Monroe wrote:
FWIW, the dbMap
FWIW, the dbMap object get populated in a "lazy" manner by default. However,
there is a way to force it to be fully loaded via a code call. You
do this by calling:
org.apache.torque.linkage.DefaultMapInit.init();
Not that this class actually exists in the generated classes and not
in the Torqu
The why is a good question, the table is not found. The tables hashmap
in the dbMap appears to be empty.
It of course is found when using the other db connection. It looks like
I'm gonna have to dig for awhile.
Thanks.
Thomas Fischer wrote:
The null ointer exception seems to come from reading
Greg Monroe wrote:
I also wonder if this isn't a PostGres version issue. If I remember the
SQL standards correctly, the query that PostGres is choking on is perfectly
valid SQL. PostGres, like MySQL and the like, have all been working to
follow the SQL Standard more closely. This could be a s
> I also wonder if this isn't a PostGres version issue. If I remember the
> SQL standards correctly, the query that PostGres is choking on is
perfectly
> valid SQL. PostGres, like MySQL and the like, have all been working to
> follow the SQL Standard more closely. This could be a standards bug i
I also wonder if this isn't a PostGres version issue. If I remember the
SQL standards correctly, the query that PostGres is choking on is perfectly
valid SQL. PostGres, like MySQL and the like, have all been working to
follow the SQL Standard more closely. This could be a standards bug in
your
I cannot reproduce this. When I run the DataTest.testUpdate in the test
project I see the following update statement in the save() method of an
updated author:
UPDATE author SET name = ? WHERE author_id = ?
Could you provide more detail how the update clause is produced ?
Thomas
> ...
> Now
12 matches
Mail list logo
