You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-user@db.apache.org by "Lopez Vellon, Ignacio" <il...@indra.es> on 2003/07/10 17:44:38 UTC
how select count(*)
Does anyone know how to perform select count(*) against a table in my database using OJB?
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Queries for M:N collections?
Posted by Rémi Bars <rb...@softeam.fr>.
Hi all, i found my bug !
it is in my p6spy library (a bug in the log module, this bug is referenced
in bugzilla)
Remi
----- Original Message -----
From: "Rémi Bars" <rb...@softeam.fr>
To: <oj...@db.apache.org>
Sent: Monday, October 27, 2003 5:10 PM
Subject: Queries for M:N collections?
> Hi all,
>
> i m trying to store an object A wich have a list of A element, when i try
> that it works first time and after i got this exception
>
> org.apache.ojb.broker.PersistenceBrokerException:
> java.lang.StringIndexOutOfBoundsException: String index out of range: -2
> at
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.getMtoNImplementor(Persiste
> nceBrokerImpl.java:921)
> at
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeCollections(Persistenc
> eBrokerImpl.java:783)
> at
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBroker
> Impl.java:2007)
> t
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl
> .java:1889)
> at
>
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl
> .java:1851)
> at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown
> Source)
> at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown
> Source)
> at org.apache.ojb.odmg.states.StateOldDirty.commit(Unknown Source)
> at org.apache.ojb.odmg.ObjectEnvelopeTable.commitAllEnvelopes(Unknown
> Source)
> at org.apache.ojb.odmg.ObjectEnvelopeTable.commit(Unknown Source)
> at org.apache.ojb.odmg.TransactionImpl.doCommitOnObjects(Unknown Source)
> at org.apache.ojb.odmg.TransactionImpl.prepare(Unknown Source)
> at org.apache.ojb.odmg.TransactionImpl.commit(Unknown Source)
>
> create table A(id int primary key not null)
>
> create table A_A(ParentID int not null, ID int not null,primary key
> (ParentID , ID))
>
>
>
> <class-descriptor class='A' table='A'>
> <field-descriptor
> name="id"
> column="id"
> jdbc-type="INTEGER"
> primarykey="true"
> autoincrement="true"
> />
>
> <collection-descriptor
> name="listOfA"
> element-class-ref="A"
> auto-retrieve="true"
> auto-update="true"
> auto-delete="false"
> indirection-table="A_A"
> >
> <fk-pointing-to-this-class column="ParentID"/>
> <fk-pointing-to-element-class column="ID "/>
> </collection-descriptor>
>
> </class-descriptor>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Queries for M:N collections?
Posted by Rémi Bars <rb...@softeam.fr>.
Hi all,
i m trying to store an object A wich have a list of A element, when i try
that it works first time and after i got this exception
org.apache.ojb.broker.PersistenceBrokerException:
java.lang.StringIndexOutOfBoundsException: String index out of range: -2
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.getMtoNImplementor(Persiste
nceBrokerImpl.java:921)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeCollections(Persistenc
eBrokerImpl.java:783)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(PersistenceBroker
Impl.java:2007)
t
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl
.java:1889)
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.store(PersistenceBrokerImpl
.java:1851)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown
Source)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.store(Unknown
Source)
at org.apache.ojb.odmg.states.StateOldDirty.commit(Unknown Source)
at org.apache.ojb.odmg.ObjectEnvelopeTable.commitAllEnvelopes(Unknown
Source)
at org.apache.ojb.odmg.ObjectEnvelopeTable.commit(Unknown Source)
at org.apache.ojb.odmg.TransactionImpl.doCommitOnObjects(Unknown Source)
at org.apache.ojb.odmg.TransactionImpl.prepare(Unknown Source)
at org.apache.ojb.odmg.TransactionImpl.commit(Unknown Source)
create table A(id int primary key not null)
create table A_A(ParentID int not null, ID int not null,primary key
(ParentID , ID))
<class-descriptor class='A' table='A'>
<field-descriptor
name="id"
column="id"
jdbc-type="INTEGER"
primarykey="true"
autoincrement="true"
/>
<collection-descriptor
name="listOfA"
element-class-ref="A"
auto-retrieve="true"
auto-update="true"
auto-delete="false"
indirection-table="A_A"
>
<fk-pointing-to-this-class column="ParentID"/>
<fk-pointing-to-element-class column="ID "/>
</collection-descriptor>
</class-descriptor>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Queries for M:N collections?
Posted by Roland Kruggel <li...@bbf7.de>.
Am Donnerstag Oktober 2 2003 11:11 schrieb LAURENT Stephane:
> Hi,
> I'm not sur to understand, but ...
> you have :
> Class A
> {
> Integer idA;
> String attribute1_A;
> String attribute2_A;
> ..
> Collection listOfA
> }
>
>
> if your repository is like this :
> <class-descriptor class="A" table="tableA">
> <field-descriptor name="idA" column="ID" jdbc-type="BIGINT"
> primarykey="true" autoincrement="true"/> <field-descriptor
> name="attribute1_A" column="a1" jdbc-type="VARCHAR"/>
> <field-descriptor name="attribute2_A" column="a2"
> jdbc-type="VARCHAR"/> ..
> <collection-descriptor name="listOfA" element-class-ref="A"
> auto-retrieve="true" auto-update="true" indirection-table="tableA_A">
> <fk-pointing-to-this-class column="idA"/>
> <fk-pointing-to-element-class column="idA"/>
> </collection-descriptor>
> </class-descriptor>
>
>
> you can getCollection of A where listOfA contain at lesat one element
> equal to wantedAInstance :
>
> crit.addEqual("listOfA",wantedAInstance);
> getCollectionbyCriteria(A.class,crit);
>
> you can getCollection of A where listOfA contain at lesat one element
> A having at least A in his listOfA collection :
>
> crit.addEqual("listOfA.listOfA",wantedAInstance);
> getCollectionbyCriteria(A.class,crit);
>
> ..
>
> is it your goal ?
> ----- Original Message -----
> From: Joe Germuska
> To: OJB Users List
> Sent: Thursday, October 02, 2003 12:00 AM
> Subject: Queries for M:N collections?
>
> At 16:44 -0500 10/1/03, Joe Germuska wrote:
> >I'm dealing with a case where I want to model an M:N relationship
> >between two objects of the same type. I have a collection
> >descriptor modeled off of the example for this on the OJB site.
> >When I go to store, I'm getting a class cast exception...
>
> For what it's worth, changing that property to a Collection
> definitely solved my problem. Which leads me to the real question:
>
> I need to construct a Query which selects collections for either
> direction of this relationship. That is, Given a parent, I need to
> find all of its children, and given a child, I need to find all of
> their possible parents.
>
> I can probably work this out with a QueryBySQL, but I'm trying to
> avoid that. I don't see any methods on Criteria to set where I can
> set something like "property contains some member"... Can anyone
> advise?
>
> Thanks in advance,
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "We want beef in dessert if we can get it there."
> -- Betty Hogan, Director of New Product Development, National
> Cattlemen's Beef Association
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org For
> additional commands, e-mail: ojb-user-help@db.apache.org
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.522 / Virus Database: 320 - Release Date: 01/10/2003
cu
--
Roland Kruggel mailto: liste@bbf7.de
System: AMD 1200Mhz, Debian woody, 2.4.20, KDE 3.1.4
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Queries for M:N collections?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:11 +0200 10/2/03, LAURENT Stephane wrote:
>you can getCollection of A where listOfA contain at lesat one
>element equal to wantedAInstance :
>
>crit.addEqual("listOfA",wantedAInstance);
>getCollectionbyCriteria(A.class,crit);
>
>you can getCollection of A where listOfA contain at lesat one
>element A having at least A in his listOfA collection :
>
>crit.addEqual("listOfA.listOfA",wantedAInstance);
>getCollectionbyCriteria(A.class,crit);
Yes, this is it. To be honest, I went ahead and tried what seemed
like the intuitive syntax before I saw your reply, and I was pleased
to see it work. Knowing now that it works, I can understand the
approach the framework takes to building the SQL, but I was hung up
on trying to imagine more pure property access. That is, in my case,
my query is something like this:
crit.addIn("items.categoryCode", categories)
Since "items" is a list, obviously it doesn't have a property
"categoryCode". Its members have that category, but at first I
thought I would at least need to somehow specify an index -- i
thought it might be something like
crit.addIn("items[*].categoryCode", categories)
Of course, now I see that OJB knows that "items" is a collection, not
a field, and so it can interpret what comes after items
(.categoryCode) differently than it would in a 1:1 join.
Thanks for your reply,
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Queries for M:N collections?
Posted by LAURENT Stephane <sl...@adequates.com>.
Hi,
I'm not sur to understand, but ...
you have :
Class A
{
Integer idA;
String attribute1_A;
String attribute2_A;
...
Collection listOfA
}
if your repository is like this :
<class-descriptor class="A" table="tableA">
<field-descriptor name="idA" column="ID" jdbc-type="BIGINT" primarykey="true" autoincrement="true"/>
<field-descriptor name="attribute1_A" column="a1" jdbc-type="VARCHAR"/>
<field-descriptor name="attribute2_A" column="a2" jdbc-type="VARCHAR"/>
...
<collection-descriptor name="listOfA" element-class-ref="A" auto-retrieve="true" auto-update="true" indirection-table="tableA_A">
<fk-pointing-to-this-class column="idA"/>
<fk-pointing-to-element-class column="idA"/>
</collection-descriptor>
</class-descriptor>
you can getCollection of A where listOfA contain at lesat one element equal to wantedAInstance :
crit.addEqual("listOfA",wantedAInstance);
getCollectionbyCriteria(A.class,crit);
you can getCollection of A where listOfA contain at lesat one element A having at least A in his listOfA collection :
crit.addEqual("listOfA.listOfA",wantedAInstance);
getCollectionbyCriteria(A.class,crit);
...
is it your goal ?
----- Original Message -----
From: Joe Germuska
To: OJB Users List
Sent: Thursday, October 02, 2003 12:00 AM
Subject: Queries for M:N collections?
At 16:44 -0500 10/1/03, Joe Germuska wrote:
>I'm dealing with a case where I want to model an M:N relationship
>between two objects of the same type. I have a collection
>descriptor modeled off of the example for this on the OJB site.
>When I go to store, I'm getting a class cast exception...
For what it's worth, changing that property to a Collection
definitely solved my problem. Which leads me to the real question:
I need to construct a Query which selects collections for either
direction of this relationship. That is, Given a parent, I need to
find all of its children, and given a child, I need to find all of
their possible parents.
I can probably work this out with a QueryBySQL, but I'm trying to
avoid that. I don't see any methods on Criteria to set where I can
set something like "property contains some member"... Can anyone
advise?
Thanks in advance,
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 01/10/2003
Re: Choosing a cache implementation
Posted by Joe Germuska <Jo...@Germuska.com>.
>
>This shouldn't be a big problem because "per-broker" cache clears its
>cache after each PB.close/PB.commit/PB.rollback event, thus at the
>latest after PB.close/PB create sequence the "new" data was used.
Wow, that clears things up; I had some idea that OJB had a
"system-wide" cache of some sort, but now I think I understand that
the cache is just within a transaction context (or transaction-ish)
to avoid cyclical object calls and such.
But wait... I know I've had situations where I've made database
changes with SQL and don't see them in the JVM runtime until I
restart the application. Well, I think I know that. I always
thought that was related to the caching.
Are there two different aspects of object caching? Am I just
confused? Maybe I need to run a few more tests.
Armin, I really appreciate your help. Thanks
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Choosing a cache implementation
Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi Joe,
sorry for the late reply - I'm little bit busy.
Joe Germuska wrote:
> Following on with my little thread about using OJB in a data load
> environment; to re-cap, I'm looking at optimizing batch data updates;
> doing them by using first-class objects and full OJB adds too much
> overhead for the purpose. My current thought is to instead do the
> updates themselves in
>
>> I think if I do this I could even invalidate the cache per ID after
>> each write and minimize the risk of dirty reads.
>
>
> I'm looking for some expert insight here -- from reading the page at
> "http://db.apache.org/ojb/objectcache.html", it appears as if the
> ObjectCacheDefaultImpl is shared, and so is a relatively safe way for me
> to approach this. This is essentially read-only data except for my
> batch load, so I do not think the warnings about transaction isolation
> are a big concern for me right now.
>
> I guess ObjectCache has a clear method too, so I could do the whole
> batch and then clear the cache.
> I'm not 100% comfortable with the risk
> that someone later might change the cache implementation to a
> "per-broker" implementation and then I wouldn't have any reliable way to
> clear all the caches.
This shouldn't be a big problem because "per-broker" cache clears its
cache after each PB.close/PB.commit/PB.rollback event, thus at the
latest after PB.close/PB create sequence the "new" data was used.
> I wonder if there should be some API way to do
> that? Or is the idea that direct cache management is a very exceptional
> condition and so there isn't any reason to be concerned about this?
hmm, a global cache clear method for all local caches? I think this is a
specific behaviour of the cache implementation. But all proposals are
welcome ;-)
regards,
Armin
>
> Thanks
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Choosing a cache implementation
Posted by Joe Germuska <Jo...@Germuska.com>.
Following on with my little thread about using OJB in a data load
environment; to re-cap, I'm looking at optimizing batch data updates;
doing them by using first-class objects and full OJB adds too much
overhead for the purpose. My current thought is to instead do the
updates themselves in
>I think if I do this I could even invalidate the cache per ID after
>each write and minimize the risk of dirty reads.
I'm looking for some expert insight here -- from reading the page at
"http://db.apache.org/ojb/objectcache.html", it appears as if the
ObjectCacheDefaultImpl is shared, and so is a relatively safe way for
me to approach this. This is essentially read-only data except for
my batch load, so I do not think the warnings about transaction
isolation are a big concern for me right now.
I guess ObjectCache has a clear method too, so I could do the whole
batch and then clear the cache. I'm not 100% comfortable with the
risk that someone later might change the cache implementation to a
"per-broker" implementation and then I wouldn't have any reliable way
to clear all the caches. I wonder if there should be some API way to
do that? Or is the idea that direct cache management is a very
exceptional condition and so there isn't any reason to be concerned
about this?
Thanks
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Help reducing OJB overhead for a data load process
Posted by Joe Germuska <Jo...@Germuska.com>.
>nobody else seems to have an idea, so will will do some bla bla ;-)
Armin:
Thanks... this seems pretty complicated, and a little risky. I
think if anything I'd rather make alternative objects that are only
used for this batch data load, and use the more limited class
descriptors for them. Seems safer, and I don't mind having separate
API for processing the batch files.
I'm thinking about actually even implementing stored procedures and
"storing" the data pretty much as it comes in and letting the
database do the heavy lifting. I think if I do this I could even
invalidate the cache per ID after each write and minimize the risk of
dirty reads. I just haven't learned out to do stored procedures in
OJB yet!
Thanks for taking the time. I wish we could get our integration
partners to use a more modern message-oriented data update approach,
but until they do, we're stuck with batch processing. I'm not sure I
can justify how or why OJB would or should make this easier for me,
even though I wish it would :-)
Joe
>I don't see any easy way to realize this completely within OJB. You
>can use MetadataManager "per thread metadata mode" to deal with
>different repository files. The "normal" repository file and you can
>load an additional "shrunk" repository were in class-descriptor all
>"big" fields removed. In your case a org class-descriptor only with
>PK and FK fields.
>
>See javadoc of MetadataManager to see the details.
>http://db.apache.org/ojb/api/org/apache/ojb/broker/metadata/MetadataManager.html
>It is now possible to use a different object metadata profile
>(normal or shrunk repository) for each thread by calling
>
>MM.loadProfile("shrunk");
>
>Next call to PBF.createPersistenceBroker return a PB instance deals
>only with the limited 'org' version.
>Only problem is the cache (I don't have a smart solution for this
>problem - any proposals are welcome ;-)). If you use a shared cache
>(e.g. ObjectCacheDefaultImpl) other threads with "normal" repository
>may get "dirty reads" of shrunked org objects. To avoid this you can
>specify a local cache for org class on class-descriptor level (e.g.
>ObjectCachePerBrokerImpl - not really good performance) or enable in
>OJB.properties the 'descriptorBasedCaches' property. Then OJB use
>separate caches for each cache defined class-descriptor based on
>ObjectCacheDescriptor instance
>(object-cache element within class-descriptor). This means if you
>declare an object-cache within class-descriptor of 'org' you will
>end up in different cache instances for each profile ("normal",
>"shrunk").
>
>Don't know if this is helpful ;-)
>
>regards,
>Armin
>
>Joe Germuska wrote:
>
>>I have a process which requires an extreme amount of overhead to
>>manage with OJB that would be so simple to do in straight SQL. I'm
>>hoping some OJB specialists can help me figure out how to tune this
>>process.
>>
>>For an application, we have a number of users who can log in to
>>operate on behalf of their organizations. In the object model,
>>there are two relevant objects: the organization (org for short)
>>and the org-agent. The org is a fairly rich object, while the
>>org-agent is merely the relationship between the agent's ID (a
>>string) and the org itself.
>>
>>I periodically get a data feed which essentially just maps agent
>>ids to organization ids. In SQL, I'd just manage a single
>>two-column table directly, and the process would be done in a
>>matter of minutes. (About five minutes using a script I've written)
>>However, in OJB, I seem to be dragging these heavy "org" objects
>>around with everything I want to do, and it makes the thing take
>>more like five hours.
>>
>>I'm thinking that I could just run the direct-SQL script instead of
>>using OJB, and then signal the application that its cache of these
>>objects may be invalid. This is probably safe, in a practical
>>sense, since the process is much more likely to insert new objects
>>than change old ones, but I can't be certain of that.
>>
>>The alternative would be to figure out a way to get OJB to accept
>>updates to objects that may or may not have been loaded yet without
>>performing a full load for each. I'm not totally clear on how OJB
>>functions here either, but I think that if I make a new object with
>>the same ID (primary key) as one for which OJB already has a cached
>>instance, then OJB isn't real happy. Maybe I'm writing my tests
>>wrong, but a few things I did to try to test this seem to bear it
>>out.
>>
>>Any advice or insight into how to achieve this best would be
>>greatly appreciated...
>>
>>Thanks
>> Joe
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
>For additional commands, e-mail: ojb-user-help@db.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Imagine if every Thursday your shoes exploded if you tied them
the usual way. This happens to us all the time with computers, and
nobody thinks of complaining."
-- Jef Raskin
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: Help reducing OJB overhead for a data load process
Posted by Armin Waibel <ar...@code-au-lait.de>.
Hi Joe,
nobody else seems to have an idea, so will will do some bla bla ;-)
I don't see any easy way to realize this completely within OJB. You can
use MetadataManager "per thread metadata mode" to deal with different
repository files. The "normal" repository file and you can load an
additional "shrunk" repository were in class-descriptor all "big" fields
removed. In your case a org class-descriptor only with PK and FK fields.
See javadoc of MetadataManager to see the details.
http://db.apache.org/ojb/api/org/apache/ojb/broker/metadata/MetadataManager.html
It is now possible to use a different object metadata profile (normal or
shrunk repository) for each thread by calling
MM.loadProfile("shrunk");
Next call to PBF.createPersistenceBroker return a PB instance deals only
with the limited 'org' version.
Only problem is the cache (I don't have a smart solution for this
problem - any proposals are welcome ;-)). If you use a shared cache
(e.g. ObjectCacheDefaultImpl) other threads with "normal" repository may
get "dirty reads" of shrunked org objects. To avoid this you can specify
a local cache for org class on class-descriptor level (e.g.
ObjectCachePerBrokerImpl - not really good performance) or enable in
OJB.properties the 'descriptorBasedCaches' property. Then OJB use
separate caches for each cache defined class-descriptor based on
ObjectCacheDescriptor instance
(object-cache element within class-descriptor). This means if you
declare an object-cache within class-descriptor of 'org' you will end up
in different cache instances for each profile ("normal", "shrunk").
Don't know if this is helpful ;-)
regards,
Armin
Joe Germuska wrote:
> I have a process which requires an extreme amount of overhead to manage
> with OJB that would be so simple to do in straight SQL. I'm hoping some
> OJB specialists can help me figure out how to tune this process.
>
> For an application, we have a number of users who can log in to operate
> on behalf of their organizations. In the object model, there are two
> relevant objects: the organization (org for short) and the org-agent.
> The org is a fairly rich object, while the org-agent is merely the
> relationship between the agent's ID (a string) and the org itself.
>
> I periodically get a data feed which essentially just maps agent ids to
> organization ids. In SQL, I'd just manage a single two-column table
> directly, and the process would be done in a matter of minutes. (About
> five minutes using a script I've written) However, in OJB, I seem to be
> dragging these heavy "org" objects around with everything I want to do,
> and it makes the thing take more like five hours.
>
> I'm thinking that I could just run the direct-SQL script instead of
> using OJB, and then signal the application that its cache of these
> objects may be invalid. This is probably safe, in a practical sense,
> since the process is much more likely to insert new objects than change
> old ones, but I can't be certain of that.
>
> The alternative would be to figure out a way to get OJB to accept
> updates to objects that may or may not have been loaded yet without
> performing a full load for each. I'm not totally clear on how OJB
> functions here either, but I think that if I make a new object with the
> same ID (primary key) as one for which OJB already has a cached
> instance, then OJB isn't real happy. Maybe I'm writing my tests wrong,
> but a few things I did to try to test this seem to bear it out.
>
> Any advice or insight into how to achieve this best would be greatly
> appreciated...
>
> Thanks
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Help reducing OJB overhead for a data load process
Posted by Joe Germuska <Jo...@Germuska.com>.
I have a process which requires an extreme amount of overhead to
manage with OJB that would be so simple to do in straight SQL. I'm
hoping some OJB specialists can help me figure out how to tune this
process.
For an application, we have a number of users who can log in to
operate on behalf of their organizations. In the object model, there
are two relevant objects: the organization (org for short) and the
org-agent. The org is a fairly rich object, while the org-agent is
merely the relationship between the agent's ID (a string) and the org
itself.
I periodically get a data feed which essentially just maps agent ids
to organization ids. In SQL, I'd just manage a single two-column
table directly, and the process would be done in a matter of minutes.
(About five minutes using a script I've written) However, in OJB, I
seem to be dragging these heavy "org" objects around with everything
I want to do, and it makes the thing take more like five hours.
I'm thinking that I could just run the direct-SQL script instead of
using OJB, and then signal the application that its cache of these
objects may be invalid. This is probably safe, in a practical sense,
since the process is much more likely to insert new objects than
change old ones, but I can't be certain of that.
The alternative would be to figure out a way to get OJB to accept
updates to objects that may or may not have been loaded yet without
performing a full load for each. I'm not totally clear on how OJB
functions here either, but I think that if I make a new object with
the same ID (primary key) as one for which OJB already has a cached
instance, then OJB isn't real happy. Maybe I'm writing my tests
wrong, but a few things I did to try to test this seem to bear it out.
Any advice or insight into how to achieve this best would be greatly
appreciated...
Thanks
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Queries for M:N collections?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 16:44 -0500 10/1/03, Joe Germuska wrote:
>I'm dealing with a case where I want to model an M:N relationship
>between two objects of the same type. I have a collection
>descriptor modeled off of the example for this on the OJB site.
>When I go to store, I'm getting a class cast exception...
For what it's worth, changing that property to a Collection
definitely solved my problem. Which leads me to the real question:
I need to construct a Query which selects collections for either
direction of this relationship. That is, Given a parent, I need to
find all of its children, and given a child, I need to find all of
their possible parents.
I can probably work this out with a QueryBySQL, but I'm trying to
avoid that. I don't see any methods on Criteria to set where I can
set something like "property contains some member"... Can anyone
advise?
Thanks in advance,
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
arrays legal for M:N collections?
Posted by Joe Germuska <Jo...@Germuska.com>.
I get a 502 error when I try to get to Scarab to see if this has been
reported or not, so I'll email and see if anyone recognizes the
issue...
I'm dealing with a case where I want to model an M:N relationship
between two objects of the same type. I have a collection descriptor
modeled off of the example for this on the OJB site. When I go to
store, I'm getting a class cast exception, presumably when this code
is run:
org.apache.ojb.broker.core.PersistenceBrokerImpl, line 781:
if (cds.isMtoNRelation())
{
currentMtoNKeys = getMtoNImplementor(cds, obj);
// delete unused m:n implementors
deleteMtoNImplementor(cds, obj, (Collection)col,
currentMtoNKeys);
}
My "col" here is an array of the element type. Is this just
something which isn't allowed? Or have I stumbled on to a bug, and
this should deal with the possibility that "col" is an Array as well?
Thanks in advance,
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: select all from extent?
Posted by Thomas Mahler <th...@web.de>.
Joe Germuska wrote:
> This seems like it should be obvious, but I'm just not getting it from
> the JavaDoc or the other docs (or searching the mailing list archives)...
>
> Is there an idiomatic way to construct a query to select all members of
> an extent from the broker?
new QueryByCriteria(MyClass, null);
A null Criteria means "select all"...
I can kind of see how to do it with OQL, but
> I'm not using the ODMG approach. (Should I? Can I mix and match?)
>
> I'm faking around it by selecting with a criteria that specifies
> instances where the primary key is not null, but I'd rather know the
> right way to do it...
>
> Thanks
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
select all from extent?
Posted by Joe Germuska <Jo...@Germuska.com>.
This seems like it should be obvious, but I'm just not getting it
from the JavaDoc or the other docs (or searching the mailing list
archives)...
Is there an idiomatic way to construct a query to select all members
of an extent from the broker? I can kind of see how to do it with
OQL, but I'm not using the ODMG approach. (Should I? Can I mix and
match?)
I'm faking around it by selecting with a criteria that specifies
instances where the primary key is not null, but I'd rather know the
right way to do it...
Thanks
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: how select count(*)
Posted by Mykola Ostapchuk <my...@sympatico.ca>.
Use getCount(query) method:
int recordsCount = broker.getCount(query);
Regards,
Mykola
----- Original Message -----
From: "Lopez Vellon, Ignacio" <il...@indra.es>
To: <oj...@db.apache.org>
Sent: Thursday, July 10, 2003 11:44 AM
Subject: how select count(*)
Does anyone know how to perform select count(*) against a table in my
database using OJB?
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-user-help@db.apache.org
Re: how select count(*)
Posted by Gerardo Arroyo <ge...@flecharoja.com>.
Hi,
I used something like this:
ReportQueryByCriteria q = QueryFactory.newReportQuery(
tasksData.class, criteria);
// define the 'columns' of the report
q.setColumns(new String[] { "count(*)"});
Iterator iter = broker.getReportQueryIteratorByQuery(q);
Integer total = new Integer(0);
if (iter.hasNext()) {
Object[] arr = (Object[]) iter.next();
total = (Integer) arr[0];
if (total == null)
total = new Integer(0);
}
On Thu, 2003-07-10 at 09:44, Lopez Vellon, Ignacio wrote:
> Does anyone know how to perform select count(*) against a table in my database using OJB?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-user-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-user-help@db.apache.org