Thanks Charles,
Right, i was still confusing, i'm in the fundamental problem case, no
where cititeria, and don't know what to do next.
Between i didn't succed to get p6spy logs, and discoverd following the
OjectCache instructions : caching works for me with PB and not with JDO!
Then i red somthing i should read before in FAQ section 3.3 "I recommend
to not use JDO now, but to use the existing ODMG api for the time being"
and wonder if this would affect my problem too...
Any suggestion / what i should do next?
Regards,
Phil
Charles Anthony wrote:
Hi,
I'm sorry to keep harping on about it, but your problem really is not the
index or indexed fields - indexs really don't come into it, at least not
yet.
Your fundamental problem is that the JDO query is not generating a where
criteria in the SQL, whereas the OJB Query is. And that is a very
fundamental problem...
As I said before, I know nothing about JDO - but in our use of OJB, we are
combining both the ODMG api and OJB PB Queries, and everything works fine.
So, yes, I don't see any technical problem with combining the two.
Cheers,
Charles
-----Original Message-----
From: Philippe Guillard [mailto:[EMAIL PROTECTED]
Sent: 03 June 2005 09:29
To: OJB Users List
Subject: Re: JDO Query / indexed column
Hi all,
Really strange, this summurizes exactly my problem:
Using JDOQuery, my database index is not used query needs 6/7/8s to
commit on big table,
logs from MySql says:
SELECT A0.ZIP,..... FROM USAZIP A0
BUT using OJB Query, i get instantly the result.
logs from MySql says
SELECT A0.ZIP,..... FROM USAZIP A0 WHERE A0.ZIP = '90001'
(I didn't try P6Spy yet).
Do you think it is an acceptable practice to use a mix of JDO (all my
retrieve, update, remove functions are with JDO pm.getObjectById() )
and add some OJB queries using The PersistenceBroker API for somes
queries with more complicated criteria on indexed fields?
Regards,
Phil
____________________________________________________________________
// JDO query 8s
public static Collection queryTest1(PersistenceManager pm) {
Query query = pm.newQuery(Usazip.class, "zip==\"90001\"");
Collection collection = (Collection) query.execute();
return collection;
}
//With parameters 7s
public static Collection queryTest2(PersistenceManager pm) {
Query query = pm.newQuery(Usazip.class, "zip==param");
query.declareParameters("String param");
Collection collection = (Collection) query.execute("90001");
return collection;
}
//query all 5/6s is less than with criteria on indexed column!!!
public static Collection queryTest3(PersistenceManager pm) {
Query query = pm.newQuery(Usazip.class);
Collection collection = (Collection) query.execute();
return collection;
}
//Directly OJB broker <1s
public static Collection brokerTest2() {
PersistenceBroker broker = null;
Collection collection = null;
try
{
broker = PersistenceBrokerFactory.defaultPersistenceBroker();
Criteria crit = new Criteria();
crit.addEqualTo("zip","90001");
QueryByCriteria query = new QueryByCriteria(Usazip.class, crit);
collection = broker.getCollectionByQuery(query);
return collection;
}
finally
{
if (broker != null) broker.close();
}
}
Philippe Guillard wrote:
Thanks a lot Martin, i'll give a try..
Phil
Martin Kalén wrote:
Philippe Guillard wrote:
Thanks Charles,
Unfortunately i get the same result without parameter. ( I use JDO
1.01 form Sun, OJB as integrated in cocoon framework).
You guess right i 've built the DB by hand before and adapted a
repository later. It is not supposed to be used at runtime, but i
get errors at runtime in case of incorrect configuration, thus i
tried configuring indexes in repository...
Any idea for which direction i should go?
The index-descriptor is (as Charles pointed out) only used if you
generate
DDL/SQL with OJB using Torque.
If you create your database "by hand", you can remove all
index-descriptor
attributes to get a cleaner OJB repository.
Also, the following is a key issue:
Charles Anthony wrote:
The database always decides what indexes to use, never OJB !
What you should do to get OJB to use database indexes is use P6Spy or
the logtrace from your RDBMS, inspect the generated statements and
then set indices accordingly (so that OJB-generated SQL can use
indices).
There are some 3rd party tools to help you time Statement execution
times and give you hints for what to set your index on (eg [1], [2]).
Regards,
Martin
[1] IronGrid IronTrack - built on top of bundled P6Spy
Presents graphical trace, "culprits" and timeline of Statement times
http://www.irongrid.com/catalog/product_info.php?products_id=32
[2] Jahia SQL Profiler - integrates with P6Spy
Somewhat old and simpler than IronTrack, but can autogenerate
index DDL
http://www.jahia.org/jahia/page377.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
___________________________________________________________
HPD Software Ltd. - Helping Business Finance Business
Email terms and conditions: www.hpdsoftware.com/disclaimer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
