On Jun 7, 2005, at 10:58 PM, Matt Hogstrom wrote:
Thanks Gianny,
As soon as I complete the deploy of SPECj I'm happy to work on these
features. Both will have a dramatic impact on performance so crawling
through the code base now is preparing me for that next set of work.
Regarding the it turns out that I was incorrect, the problem was not
the Date field but was a java.math.BigDecimal field. The database
column is a DOUBLE and the Java type is java.math.BigDecimal. I
worked with Jeremy earlier today on this and am working out a patch.
This brings up a question. In TranQL is there a framework to provide
database specific mappings and transforms? For instance DB2 and
Oracle both provide support for converting a DOUBLE to long, int,
short, byte, float, java.math.BigDecimal, boolean or
java.lang.String. I'm not sure about Derby. The point is that there
are extensions to common drivers that provide additional conversion
that simplifies life. From what I can see TranQL may be artificially
limiting by requiring more TypeConverters than needed based on the
JDBC driver that is being used.
After thinking about this overnight, isn't the solution to state in the
openejb plan that the column is Numeric? Then, even though it is
actually Decimal, tranql will use the get/set methods for
Numeric<>BigDecimal and force the driver to do the type conversions.
thanks
david jencks
Also, with regard to doing JOINS and providing support for SELECT FOR
UPDATE different databases have different issues. For instance,
Oracle allows a SELECT FOR UPDATE in a JOIN and DB2 does not.
Although, DB2 has specialized predicated that would allow for an
UPDATE in a JOIN that became available in DB2 8.2. I believe sybase
does not support a SELECT FOR UPDATE semantic but can use a null
UPDATE command to obtain a database lock. I guess my question is does
TranQL allow for database specific query and update generators to be
plugged inthat will allow for maximal SQL optimization ?
I'l let you know how my testing goes.
Cheers.
Matt
----- Original Message ----- From: "Gianny Damour"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, June 07, 2005 10:52 PM
Subject: Re: [openejb-dev] FindByPrimaryKey executes two Queries
Hello Matt,
I think that to do that for FindByPrimaryKey is rather simple. Yet,
it would be a non-optimal patch as it does not solve the problem as a
whole.
As a matter of fact, I have started to work on CMP and CMR
prefetching (see http://issues.apache.org/jira/browse/GERONIMO-665
for more details). Based on my current estimates, you should expect
something working by end of next week.
Meanwhile, if you want to give us a hand with respect to database
operations, here are two things that I think we want to have:
* batch updates: I think that this is an easy one and a good way to
get started with TranQL; and
* cache across transactions: I think that it is much more complex.
Please note that I am happy to provide my support if you want to work
on any of these two items.
BTW, have you been able to identify the problem associated to the
java.sql.Date field?
Thanks,
Gianny
On 8/06/2005 12:36 PM, Matt Hogstrom wrote:
I've been testing FBK and found that there are two queiries being
executed. First a SELECT is done against the PK for the bean and
that is followed by a SELECT for the columns of the bean.
Performance can be improved by executing the second query only and
getting the PK and all the coluns in one shot. Can we make the
defulat for FBK and EJBQL queries to get all the data straight away
as the default.
Is this a simple change?
