OJB in Maven repository
Hi folks, I've put the 1.0.4 release into the maven repository. If all goes well, it should be visible sometime tomorrow (if not earlier). Please let me know whether it works (esp. the dependencies in the pom), because I'm not a maven user myself, rather I've been strictly following the release guide. cheers, Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caused by: org.apache.ojb.broker.util.sequence.SequenceManagerException: Can't build new sequence
excuse me for doing before reading;). I replaced the repository_internal and it is OK now. Thanks! 2006/1/10, Armin Waibel <[EMAIL PROTECTED]>: > > Hi Dennis, > > Dennis Bekkering wrote: > > Hi, > > > > In my previous mail I said that it would probably be OK if I restart the > > server. I made sure there is an entry SEQ_appointment but I still cannot > > insert records due to this error. Any hints? > > > > Did you note in release-notes (1.0.4) in section CHANGES that a > deprecated column in sequence table was removed? > > > * Internal used OJB_HL_SEQ table changed. Remove of deprecated column. >If the SequenceManagerHighLowImpl was used and problems occur after > upgrade, please >drop and recreate this table without removed column > > > Maybe this cause the problem. > > regards, > Armin > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- mvg, Dennis
Re: Caused by: org.apache.ojb.broker.util.sequence.SequenceManagerException: Can't build new sequence
Hi Dennis, Dennis Bekkering wrote: Hi, In my previous mail I said that it would probably be OK if I restart the server. I made sure there is an entry SEQ_appointment but I still cannot insert records due to this error. Any hints? Did you note in release-notes (1.0.4) in section CHANGES that a deprecated column in sequence table was removed? * Internal used OJB_HL_SEQ table changed. Remove of deprecated column. If the SequenceManagerHighLowImpl was used and problems occur after upgrade, please drop and recreate this table without removed column Maybe this cause the problem. regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: lazy loading 1.0.4
Dennis Bekkering wrote: Armin, It was the cache setting not the lazy loading.Fast as lightning again ;-) Strange though that without caching the 2nd number of queries is less? Indeed that's strange! Are you sure that no cache was used in your test (e.g. enable logging for class org.apache.ojb.broker.cache.CacheDistributor and check output)? If yes, it needs detailed analysis. In this case please add a bug report in JIRA with detailed description to reproduce the behavior. regards, Armin thanks, Dennis did you notice that the ObjectCache configuration moved from OJB.properties to repository file between rc7 and 1.0.4? You have to declare the cache within the jdbc-connection-descriptor using a object-cache element. http://db.apache.org/ojb/docu Does that mean that there is no caching at all now? Maybe that's the reason why there are more queries in 1.0.4. The thing is that I get just one query ,no joins, when i select all organisations from rc7 while there are some references that are not interfaces so they cannot be proxies anyway?? When I select 1 organisation I get all reference data with it when I call the getters. Calling all orgs on 1.0.4 I gives outer joins the 2nd time. : SQL:SELECT A0.id,A0.lastmodified,A0.creationdate,A0.version ,A0.fax, A0.fieldofinterest,A0.name,A0.noofemployee,A0.phone,A0.postaladress, A0.postalcity,A0.postalzip,A0.url,A0.visitadress,A0.visitcity, A0.visitzip, A0.chamberofcommerceno ,A0.immediateparentid,A0.ultimateparentid, A0.postalcountryid,A0.organisationbrancheid,A0.visitcountryid, A0.organisationtypeid FROM organisation A0 [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl ] DEBUG: SQL:SELECT A0.id,A0.lastmodified,A0.creationdate,A0.version,A0.code, A0.name, A0.number FROM country A0 WHERE A0.id = ? regards, Dennis 2006/1/9, Armin Waibel <[EMAIL PROTECTED]>: Hi Dennis, if I summarize your posted sql-queries we will get 1.0.4: FROM organisation A0 FROM country A0 WHERE A0.id = ? FROM tablemodel A0 WHERE A0.name = ? FROM field A0 WHERE A0.id = ? FROM fieldtype A0 WHERE A0.id = ? FROM reference A0 WHERE A0.parenttablemodelid = ? FROM rendertype A0 WHERE A0.id = ? FROM tablemodel A0 WHERE A0.id IN (?,?,?,?) FROM field A0 WHERE A0.id IN (?,?) FROM fieldtype A0 WHERE A0.id = ? FROM field A0 WHERE A0.parenttablemodelid = ? FROM fieldtype A0 WHERE A0.id IN (?,?,?) FROM tablemodel A0 WHERE A0.id = ? rc7: FROM organisation A0 FROM country A0 WHERE A0.id = ? FROM tablemodel A0 WHERE A0.name = ? FROM field A0 WHERE A0.parenttablemodelid = ? FROM fieldtype A0 WHERE A0.id IN (?,?) FROM reference A0 WHERE A0.parenttablemodelid = ? Seems that lazy loading works, because there is no query for the m:n and 1:n references. Think the other queries are the result of the 1:1 references and additional queries if the referenced object has references too or some prefetching stuff. If this is the case you could try to enable lazy loading for some 1:1 references too and check the generated queries again. you post ProxyFactoryClass=org.apache.ojb.broker.core.proxy.ProxyFactoryCGLIBImpl ObjectCacheClass=org.apache.ojb.broker.cache.ObjectCacheDefaultImpl did you notice that the ObjectCache configuration moved from OJB.properties to repository file between rc7 and 1.0.4? You have to declare the cache within the jdbc-connection-descriptor using a object-cache element. http://db.apache.org/ojb/docu/guides/objectcache.html regards, Armin Dennis Bekkering wrote: Hello, I recently switched from rc7 to 1.0.4 and lazy loading seem to happen any more. Can someone please check my config out. 1.0.4 fires twice as much queries? thanks. sql output get all organisations 1.0.4 just after clear cache [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: SQL:SELECT A0.id,A0.lastmodified,A0.creationdate,A0.version,A0.fax, A0.fieldofinterest, A0.name,A0.noofemployee,A0.phone,A0.postaladress, A0.postalcity,A0.postalzip,A0.url,A0.visitadress,A0.visitcity, A0.visitzip, A0.chamberofcommerceno,A0.immediateparentid,A0.ultimateparentid, A0.postalcountryid ,A0.organisationbrancheid,A0.visitcountryid, A0.organisationtypeid FROM organisation A0 [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: SQL:SELECT A0.id ,A0.lastmodified,A0.creationdate,A0.version,A0.code, A0.name, A0.number FROM country A0 WHERE A0.id = ? [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl ] DEBUG: SQL:SELECT A0.id,A0.lastmodified,A0.creationdate,A0.version, A0.defaultvalue, A0.fixheader,A0.groupby,A0.indescriptor,A0.name,A0.subtablesheight , A0.descriptorfieldid,A0.defaultqueryid,A0.quicksearchqueryid FROM tablemodel A0 WHERE A0.name = ? [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: SQL:SELECT A0.id,A0.lastmodified,A0.creationdate,A0.version, A0.defaultvalue, A0.indescriptor,A0.name,A0.ordr,A0.showintable,A0.sortdown, A0.fieldtypeid , A0.fieldcollectionid,A0.parenttablemodelid,A0
Re: OJB 1.0.4 and ODMG Database.makePersistent
Hi Dirk, Kessler, Dirk wrote: There appears to be a change in behavior in the Database.makePersistent method. In OJB 1.0RC7 the Database.makePersistent class would update the primary key field of the object being persisted (autoincrement) even before the transaction was committed (I.E. right after the makePersistent call). It appears that in OJB 1.0.4 the primary key value does not get updated until the transaction is committed. yep, this change was needed to harmonize OJB behavior with SequenceManager based on database identity columns. In this case it's not possible to set the PK values when the object is stored (#makePersistent call), only after the object is written to DB. Only this way OJB will show the same behavior for all DB/PK-generation. Is there any way to have makePersistent set the primary key value (it can't be a transient value, it has to be the balue eventually stored in the database)? It would be easy to implement a method which lookup the SequenceManager obtain the next PK value and set this value in your object - but this will cause some overhead. Why do you need the "PK assign before store" functionality? regards, Armin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
uses OUTER JOIN by default... --> BUG or FUNCTIONALITY ?
After some tests found out that OJB generates LEFT OUTER JOIN instead of
INNER JOIN in a 1:N relationship if both ends are same class.
Is that a planned functionality or a bug?
In my case I need 1:N relationship to be made from MyClass to Collection
of MyClasses... How can I force then OJB to generate INNER JOIN in that
case?
-Sergey
-Original Message-
From: Manukyan, Sergey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 9:00 AM
To: OJB Users List
Subject: uses OUTER JOIN by default...
Hi,
I just moved to OJB 1.0.4. One thing I noticed is that it started
generating OUTER JOIN although I didn't specify it to do so. In my case
with ReportQuery with following columns:
String[] queryColumns = new String[] {
"allChildren.addressLine1",
"allChildren.addressLine2",
"allChildren.addressLine4",
"allChildren.addressLine5",
"allChildren.allRequisitionTypesOfSupplier.reqType"
};
It generates OUTER JOIN for "allChildren" and INNER JOIN for
"allRequisitionTypesOfSupplier" when I need only INNER JOINS.
Please advice, is it a bug or should I somehow specifically tell OJB to
use INNER JOIN?
Thank you,
Sergey
**
** LEGAL DISCLAIMER **
**
This E-mail message and any attachments may contain
legally privileged, confidential or proprietary
information. If you are not the intended recipient(s),
or the employee or agent responsible for delivery of
this message to the intended recipient(s), you are
hereby notified that any dissemination, distribution
or copying of this E-mail message is strictly
prohibited. If you have received this message in
error, please immediately notify the sender and
delete this E-mail message from your computer.
-
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]
uses OUTER JOIN by default...
Hi,
I just moved to OJB 1.0.4. One thing I noticed is that it started
generating OUTER JOIN although I didn't specify it to do so. In my case
with ReportQuery with following columns:
String[] queryColumns = new String[] {
"allChildren.addressLine1",
"allChildren.addressLine2",
"allChildren.addressLine4",
"allChildren.addressLine5",
"allChildren.allRequisitionTypesOfSupplier.reqType"
};
It generates OUTER JOIN for "allChildren" and INNER JOIN for
"allRequisitionTypesOfSupplier" when I need only INNER JOINS.
Please advice, is it a bug or should I somehow specifically tell OJB to
use INNER JOIN?
Thank you,
Sergey
**
** LEGAL DISCLAIMER **
**
This E-mail message and any attachments may contain
legally privileged, confidential or proprietary
information. If you are not the intended recipient(s),
or the employee or agent responsible for delivery of
this message to the intended recipient(s), you are
hereby notified that any dissemination, distribution
or copying of this E-mail message is strictly
prohibited. If you have received this message in
error, please immediately notify the sender and
delete this E-mail message from your computer.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: bad sql on n-m relation to subclassed object
Hi jakob, Ok, it is working with 1.0.4. But if i want retreive the super class alone, a wrong SLQ query is made, I have seen on the forum that is a bug. My question is : do you know if this defect will be fixed on 1.0.5 ? Best regards Nicolas DELAHAYE >hi nicolas, > >ojb just release 1.0.4. could you please try this as well ? > >jakob Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,34 /mn) ; tél : 08 92 68 13 50 (0,34/mn) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Caused by: org.apache.ojb.broker.util.sequence.SequenceManagerException: Can't build new sequence
Hi, In my previous mail I said that it would probably be OK if I restart the server. I made sure there is an entry SEQ_appointment but I still cannot insert records due to this error. Any hints? thanks, Dennis
ERROR: Can't lookup new HighLowSequence for field id using sequence name SEQ_appointment
Hi, 1.0.4 seem to be case sensitive or something else is wrong, anyway when I change SEQ_Appointment to SEQ_appointment in the ojb_hl_seq table I still get the error. It will propbably be OK when I restart my server but I like to do that at night and not in the middle of the day. Is there a way to reset the HiLo manager at runtime? thanks, Dennis
