Re: Deleting from collection
Thanks. I'm working on a patch. When I get it working, I'll send it so you can evaluate it. Jay On 4/16/05, Jakob Braeuchi <[EMAIL PROTECTED]> wrote: > hi jay, > > i opened an issue in jira http://issues.apache.org/jira/browse/OJB-23 > > jakob > > Jakob Braeuchi schrieb: > > hi jay, > > > > > > Jay Sissom schrieb: > > > >> I understand that, but shouldn't it NOT delete items that were never > >> in the database? In my code example below, I add something to the > > > > > > the problem is, tat ojb does not have an internal state to track whether > > the object is persistent or not. > > > >> list that never was in the database, then OJB tries to delete it > >> anyway. How can it delete something when the primary key is null? > > > > > > we could try to check the pk for null values (primitive pk are still a > > problem) before adding an object to the deleted-list. > > > > jakob > > > >> > >> > >> On 4/15/05, Jakob Braeuchi <[EMAIL PROTECTED]> wrote: > >> > >>> hi jay, > >>> > >>> this is a feature of the RemovalAwareCollection. it tries to delete all > >>> removed items from the database. > >>> > >>> jakob > >>> > >>> Jay Sissom schrieb: > >>> > Hello, we have a mapping with a 1:m relation in it: > > table="PUR.PUR_REQS_T"> > primarykey="true" > sequence-name="PUR.REQS_ID" autoincrement="true"/> > ... many other fields . > name="version"/> > auto-delete="object" proxy="true" > element-class-ref="edu.iu.uis.pur.req.bo.RequisitionItem" > name="items"> > > > > > table="PUR.PUR_REQS_ITM_T"> > name="requisitionId" primarykey="true"/> > name="itemLineNumber" primarykey="true"/> > many other fields... > name="version"/> > > > There are times in our process where we add a new item to the items > collection in our Requisition, then we delete it before saving the > collection. > > When we do this, we get an OptimisticLockException because OJB is > trying to delete the object that was never in the table. Here is > sample code that causes this: > > Requisition req = reqService.getRequisitionById(new Integer(1517)); > > // Add a blank one > RequisitionItem ri = new RequisitionItem(); > req.getItems().add(ri); > > // Remove it > req.getItems().remove(ri); > > broker.store(req); > > Is this because of something we are doing or is it a bug? We're using > version 1.0.0. > > Thanks > Jay > > - > 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] > >> > >> > > > > - > > 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]
Re: Deleting from collection
hi jay, i opened an issue in jira http://issues.apache.org/jira/browse/OJB-23 jakob Jakob Braeuchi schrieb: hi jay, Jay Sissom schrieb: I understand that, but shouldn't it NOT delete items that were never in the database? In my code example below, I add something to the the problem is, tat ojb does not have an internal state to track whether the object is persistent or not. list that never was in the database, then OJB tries to delete it anyway. How can it delete something when the primary key is null? we could try to check the pk for null values (primitive pk are still a problem) before adding an object to the deleted-list. jakob On 4/15/05, Jakob Braeuchi <[EMAIL PROTECTED]> wrote: hi jay, this is a feature of the RemovalAwareCollection. it tries to delete all removed items from the database. jakob Jay Sissom schrieb: Hello, we have a mapping with a 1:m relation in it: table="PUR.PUR_REQS_T"> primarykey="true" sequence-name="PUR.REQS_ID" autoincrement="true"/> ... many other fields . name="version"/> auto-delete="object" proxy="true" element-class-ref="edu.iu.uis.pur.req.bo.RequisitionItem" name="items"> many other fields... There are times in our process where we add a new item to the items collection in our Requisition, then we delete it before saving the collection. When we do this, we get an OptimisticLockException because OJB is trying to delete the object that was never in the table. Here is sample code that causes this: Requisition req = reqService.getRequisitionById(new Integer(1517)); // Add a blank one RequisitionItem ri = new RequisitionItem(); req.getItems().add(ri); // Remove it req.getItems().remove(ri); broker.store(req); Is this because of something we are doing or is it a bug? We're using version 1.0.0. Thanks Jay - 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] - 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]
Re: Deleting from collection
hi jay, Jay Sissom schrieb: I understand that, but shouldn't it NOT delete items that were never in the database? In my code example below, I add something to the the problem is, tat ojb does not have an internal state to track whether the object is persistent or not. list that never was in the database, then OJB tries to delete it anyway. How can it delete something when the primary key is null? we could try to check the pk for null values (primitive pk are still a problem) before adding an object to the deleted-list. jakob On 4/15/05, Jakob Braeuchi <[EMAIL PROTECTED]> wrote: hi jay, this is a feature of the RemovalAwareCollection. it tries to delete all removed items from the database. jakob Jay Sissom schrieb: Hello, we have a mapping with a 1:m relation in it: ... many other fields . many other fields... There are times in our process where we add a new item to the items collection in our Requisition, then we delete it before saving the collection. When we do this, we get an OptimisticLockException because OJB is trying to delete the object that was never in the table. Here is sample code that causes this: Requisition req = reqService.getRequisitionById(new Integer(1517)); // Add a blank one RequisitionItem ri = new RequisitionItem(); req.getItems().add(ri); // Remove it req.getItems().remove(ri); broker.store(req); Is this because of something we are doing or is it a bug? We're using version 1.0.0. Thanks Jay - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proxy, Prefetching, Memory Usage
hi andreas,
i opened an issue in jira
http://issues.apache.org/jira/browse/OJB-22
jakob
Jakob Braeuchi schrieb:
hi andreas,
ojb selects all columns but creates proxies instead of fully
materialized Article objects.
what related object do you want to prefetch here ?
jakob
Andreas Bohnert schrieb:
hi,
may someone can help me with the proxies, please!
everything works fine, prefetching works as it should, but when OJB
initially selects the oid's, it does select all fields instead of
just the pk!
let's say, there is a table 'Article' with 200 000 objects.
I have written an Article Class, an ArticleProxy and an
ArticleInterface. The proxy is configured in the repository_user.xml
like this:
When I select the Article table I use a CollectionByQuery.
Criteria crit = new Criteria();
crit.addEqualTo(...
crit.addEqualTo(...
QueryByCriteria q = new QueryByCriteria( Article.class,
crit );
q.addOrderBy("articleId", true);
col = broker.getCollectionByQuery(query);
When I look at the sql statement, I can see, that OJB selects ALL
fields (in this case articleId and data ) instead of just the primary
key!
I get a huge memory usage because of this select, and it seems, that
this is because of the 'data' field, which is very big.
to get around this, I select the oid's with a ReportQuery, and build
the proxies like this:
List oids = getReportQueryList(q);
RemovalAwareCollection rows = new RemovalAwareCollection();
for (Iterator it = oids.iterator(); it.hasNext(); ) {
Object[] row = (Object[]) it.next();
Integer oid = (Integer) row[0];
rows.add( VirtualProxy.createProxy( broker.getPBKey(),
ArticleProxy.class,
new Identity( Article.class, Article.class, row)
)); }
this works fine, but the prefetching does not work anymore! when I
access a getter, I get the data objects one by one.
what's wrong with this??
thanks for your help,
andreas
-
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]
Re: Proxy, Prefetching, Memory Usage
hi andreas,
ojb selects all columns but creates proxies instead of fully
materialized Article objects.
what related object do you want to prefetch here ?
jakob
Andreas Bohnert schrieb:
hi,
may someone can help me with the proxies, please!
everything works fine, prefetching works as it should, but when OJB
initially selects the oid's, it does select all fields instead of just
the pk!
let's say, there is a table 'Article' with 200 000 objects.
I have written an Article Class, an ArticleProxy and an
ArticleInterface. The proxy is configured in the repository_user.xml
like this:
When I select the Article table I use a CollectionByQuery.
Criteria crit = new Criteria();
crit.addEqualTo(...
crit.addEqualTo(...
QueryByCriteria q = new QueryByCriteria( Article.class,
crit );
q.addOrderBy("articleId", true);
col = broker.getCollectionByQuery(query);
When I look at the sql statement, I can see, that OJB selects ALL
fields (in this case articleId and data ) instead of just the primary
key!
I get a huge memory usage because of this select, and it seems, that
this is because of the 'data' field, which is very big.
to get around this, I select the oid's with a ReportQuery, and build
the proxies like this:
List oids = getReportQueryList(q);
RemovalAwareCollection rows = new RemovalAwareCollection();
for (Iterator it = oids.iterator(); it.hasNext(); ) {
Object[] row = (Object[]) it.next();
Integer oid = (Integer) row[0];
rows.add( VirtualProxy.createProxy( broker.getPBKey(),
ArticleProxy.class,
new Identity( Article.class, Article.class, row)
)); }
this works fine, but the prefetching does not work anymore! when I
access a getter, I get the data objects one by one.
what's wrong with this??
thanks for your help,
andreas
-
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]
RE: Sequence managers and insert triggers
Mike -- Have you considered having OJB use a stored procedure to handle the insert operations? If you do so, you could have the stored procedure return to ojb the 'auto-number' value that was assigned by the trigger. This is what I had to do on a prior project, and that effort lead to the introduction of stored procedure support for insert, update and delete operations. It's been almost a year since I used Oracle in that manner, but I believe the phrase that the SP would use to return the trigger-assigned auto-number to it's 'caller' is "RETURNING". Check out http://db.apache.org/ojb/docu/howtos/howto-work-with-stored-procedures.html, and you'll see the examples that I posted when we implemented the SP support for IUD operations. The example referenced above acquires the next value from a sequence, uses it in the insert operation and returns it to the caller. I believe you could do the same sort of thing with a value that's assigned via the insert trigger. Ron Gallagher Atlanta, GA -Original Message- From: Mike Jackson [mailto:[EMAIL PROTECTED] Sent: Friday, April 15, 2005 7:10 PM To: 'OJB Users List' Subject: RE: Sequence managers and insert triggers That's basically how it works. We have triggers which upon insert will populate the "autonumber" fields. The triggers didn't look to see if the autonumber was already populated so if I had used the sequence based implementation I'd have ended up incrementing the sequence twice and none of my fk's would have the proper information in them. This would probably cause integrity constraint violations, but we've since changed the triggers to detect if the autonumber is populated. The dba isn't completely happy with this solution (ojb gets the sequence numbers and populates, anything else doesn't), but he's ok with it. The "normal" route for records is to be inserted for the master record with a stored procedure, but the "child" tables are all direct inserts with triggers to take care of things. --mikej -=- mike jackson [EMAIL PROTECTED] > -Original Message- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Friday, April 15, 2005 3:42 PM > To: OJB Users List > Subject: Re: Sequence managers and insert triggers > > > Hi Mike, > > think I don't understand your problem (never used insert trigger), so > be patience. If you are using a insert trigger I assume the trigger > set the PK value on insert of new objects? Or do you using a stored > procedure to get the key or to insert the whole object? > > OJB supports database generated sequences. A sequence manager > supporting this kind of key generation can be found here: > http://db.apache.org/ojb/docu/guides/sequencemanager.html#Data > base+sequences+based+implementation > > The SequenceManagerNativeImpl supports database identity columns, > don't know if Oracle supports this (the exception indicate it > doesn't). > > regards, > Armin > > Mike Jackson wrote: > > Actually I take it back, I was getting a -2, but when I got the > > attributes on the identity column set properly I'm getting a > > "java.lang.UnsupportedOperationException: This feature is not > > supported by this implementation". Perhaps this is the > wrong sequence > > manager to use on oracle? > > > > --mikej > > -=- > > mike jackson > > [EMAIL PROTECTED] > > > > > > > >>-Original Message- > >>From: Mike Jackson [mailto:[EMAIL PROTECTED] > >>Sent: Friday, April 15, 2005 2:45 PM > >>To: 'OJB Users List' > >>Subject: Sequence managers and insert triggers > >> > >> > >>I'm running on an Oracle database (8i) with insert triggers to > >>create artifical keys for my table records. The howtos seemed to > >>indicate that SequenceManagerNativeImpl might be the proper sequence > >>manager to use but the keys are coming out goofy, so clearly I'm not > >>understanding or something. > >>Which of the sequence managers should I be using? I've got other > >>applications using the same database, so removing the triggers and > >>using the native sequences via OJB isn't an option at this time. > >> > >>--mikej > >>-=- > >>mike jackson > >>[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] > > > > > > > > - > 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,
