Re: ODMG ordering with circular pairs
Thanks.
Response is in red.
I'm suspecting a bug.
Regards.
On 3/5/06, Armin Waibel <[EMAIL PROTECTED]> wrote:
>
> Hi Bruno,
>
> whew! Sounds really complex, I try my best...
>
> The first problem is the bidirectional reference between P1, P2. To
> establish the FK (e.g. in P1 from P2) the referenced object (P2) have to
> be persistent (else the PK of P2 will be 'null' and OJB will set FK in
> P2 'null' too).
> In CircularTest you can find examples for handling bidirectional
> references (with DB constraints) e.g.
> CircularTest#testBidirectionalWithConstraint()
>
> http://svn.apache.org/viewcvs.cgi/db/ojb/branches/OJB_1_0_RELEASE/src/test/org/apache/ojb/odmg/CircularTest.java?view=markup
>
> Say we only want to insert P1,P2. In this case you can do
>
> new P1
> new P2
> flush (now both PK values exist)
> set ref P1 to P2
> set ref P2 to P1
> commit
>
> But there are other possibilities to store P1<-->P2 (see test-suite
> examples)
>
> Generally the ordering used by OJB first try to insert the 1:1
> references of an object then the object itself and then the 1:n, m:n
> references (if you don't like it, it's possible to disable OJB's
> ordering).
>
> >
> > Now, with the OJB 1.0.4, circular or 1:1 cross references shouldn't
> > require flush().
>
> This is not correct. It only mean that it is possible to handle
> bidirectional references and the user should take a look in CircularTest
>
> http://db.apache.org/ojb/docu/guides/odmg-guide.html#Circular-+and+Bidirectional+References
>
>
> > I don't known how it has been made, but i assume it works.
> > So, i consider now that OJB can find the good order (and the back on
> first
> > object to put last reference), however we still continue to create,
> > reference, unreference, delete with the DB sequence.
> >
> > But i'm going to try to give you an example, that worked before 1.0.4.
> (with
> > flush()) and do not any more.
>
> I think it worked "accidental". Before 1.0.4 when *not* using database
> identity columns (like mysql supports) the PK's are created before the
> object was stored to DB (create PK for P1 and P2, resolve references,
> set FK, insert objects).
>
>
> >
> > -consider the circular pair of objects P1 and P2 (1:1 relation
> > , cross-referenced)
> > -consider now that we have a "M"aster object, that have a collection
> > of "D"etails obects, themselves referencing an instance of P1. Let's
> call
> > master object M, and details objects D.
> > - consider a last refrence relation between P1 and M (the master)
> >
> > So, all writing process is done like this (assume "new" is instanciating
> and
> > locking at the same time):
> >
>
> > it's schematic but I believe there is all to explain.
> >
> > Our first problem was, that, after commit, P1 was not referencing M in
> > database. I deduced that after a flush(), new locked objects (before
> flush)
> > can't reference new ones created before flush too (a second time). Humm,
> > strange... we check all code : No apparent mistakes.
Understand reference after have been made, and not in the database.
It can be a bug for me. the reference is between 2 new instanciated and
flushed object. We have tested many times, and can't understand at all.
>
> > Then, I found this about 1.0.4 releases notes [[OJB-18] - ODMG ordering
> > problem with circular/bidirectional 1:1 references]. Well, OJB finds
> the
> > good order now and close the circular schema, fine. So we tried to
> remove
> > [flush #2] and process worked.
> >
> > After, i said to all my team to remove flush(). Everyone was happy ! And
> > after [flush #1] was removed, process crashed with the FK constraints P2
> to
> > P1 (you known, the circular pair) . It seems ODMG (without any flush)
> does
> > not find the good order to solve a "far" circular pair. I don't known
> why at
> > all.
>
> Sorry for the hassle. The explanation is given above. You should always
> ask "when will the PK exist" -> after the object is inserted. So to set
> the FK's of a P1<-->P2, P2 have to be persistent to assign the FK in P1
> and P1 have to be persistent to assign the FK in P2 -> impossible to
> find a order.
> E.g. new P1, P2, set both references and then lock P1 or P2, OJB will
> only resolve one reference, e.g. commit call--> set FK in P2 (P1 PK is
> 'null' --> FK 'null'), insert P2, set FK in P1 (PK of P1), insert P1.
>
> >
> > Don't forget we have there a "double inside" circular reference (P1 & P2
> > inside M-D-P1 & P1-M). At first, i didn't think about resolve this
> > construction without 2 flushes minimum. And now, i have only one! Sorry
> for
> > headache, but i'm lost too.
> >
>
> Isn't it great?
>
> For example, the code below should work too (with one flush)
>
> > [tx.begin]
> > - new M
> > - loop of (D)
> { new D (assume that mean add D to list/collection in M)
> D references M (think this should work ,but maybe this have be done
> after flush too)
> new P1 ,
> D references P1
> new P2 ,
> flush() (now all PK of all object should exis
Re: OJB 1.0.4 Error: Oracle thin driver cannot insert CLOB values with length>4000
Hi Ailish,
please set log-level for PlatformOracle9iImpl to DEBUG (e.g. when using
OJB console logging set entry in change entry
org.apache.ojb.broker.platforms.PlatformOracle9iImpl.LogLevel=DEBUG).
Do you get any notes about connection unwarp problems ("... could not
unwrap ..."). Seems that OJB fallback to default Oracle LOB handling,
instead using Oracle9i.
regards,
Armin
Byrne, Ailish M wrote:
We can't figure out why we are sporadically receiving the exception
below. We are using OJB 1.0.4, and our platform is set to Oracle9i.
Any help would be much appreciated.
Thank you,
Ailish
2006-03-03 14:25:59,107 [TP-Processor16] ERROR
org.apache.ojb.broker.accesslayer.JdbcAccessImpl ::
* SQLException during execution of sql-statement:
* sql statement was 'UPDATE FP_MAINTENANCE_DOCUMENT_T SET
VER_NBR=?,FDOC_EXPLAIN_TXT=?,LOCK_REPRESENTATION_TXT=?,LOCKED_IND=?,DOCU
MENT_CONTENTS=? WHERE FDOC_NBR = ? AND VER_NBR = ? '
* Exception message is [Oracle thin driver cannot insert CLOB values
with length>4000. (Consider using Oracle9i as OJB platform.)]
* Vendor error code [0]
* SQL state code [null]
* Target class is 'org.kuali.core.document.MaintenanceDocumentBase'
* PK of the target object is [financialDocumentNumber=97177]
* Source object:
maintenanceDocumentBasedocumentHeaderId(versionNumber,level,comp,app,ack
,fyi)=97177(2,0,false,false,false,false)
* The root stack trace is -->
* java.sql.SQLException: Oracle thin driver cannot insert CLOB values
with length>4000. (Consider using Oracle9i as OJB platform.)
at
org.apache.ojb.broker.platforms.PlatformOracleImpl.setObjectForStatement
(Unknown Source)
at
org.apache.ojb.broker.platforms.PlatformOracle9iImpl.setObjectForStateme
nt(Unknown Source)
at
org.apache.ojb.broker.accesslayer.StatementManager.setObjectForStatement
(Unknown Source)
at
org.apache.ojb.broker.accesslayer.StatementManager.bindUpdate(Unknown
Source)
at
org.apache.ojb.broker.accesslayer.JdbcAccessImpl.executeUpdate(Unknown
Source)
...
-
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: OJB and the X-Files... :)
Hi Chris,
it was fixed (by Jakob) in OJB_1_0_RELEASE branch and will be included
in OJB 1.0.5.
regards,
Armin
Armin Waibel wrote:
Hi Chris,
Christopher Lowe wrote:
Thanks Armin,
Please let us know when it is fixed. When is OJB 1.0.5 scheduled to be
released?
Hope we can fix it in a few days and start with the vote for 1.0.5 next
week.
regards,
Armin
Regards,
Chris
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Thursday, March
02, 2006 9:48 PM
To: OJB Users List
Subject: Re: OJB and the X-Files... :)
Hi Chris,
thanks much for detailed description. Yes, I can reproduce this issue
with latest from OJB_1_0_RELEASE branch too (I checked in a test case:
InheritanceMultipleTableTest#testLookupByIdentity_2()).
You are right it's a bug. We will fix this ASAP.
regards,
Armin
Christopher Lowe wrote:
Hi Armin,
I've been able to successfully recreate this error with the
InheritanceMultipleTableTest Test cases. Again I'm using the broker API
and
the latest code from SVN OJB_1_0_RELEASE.
I added the code below to the test and like I described with my project
when
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel
is
set to WARN it does not return the right class and when I set
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel
to
DEBUG it returns the right class.
Employee employee = new Employee();
employee.setId(newEx1.getId());
employee.setId_2(newEx1.getId_2());
Identity employee_oid =
broker.serviceIdentity().buildIdentity(employee);
Employee employee1 = (Employee)
broker.getObjectByIdentity(employee_oid);
log.debug("Employee: " + employee1);
assertEquals(Executive.class.getName(),
employee1.getClass().getName());
Please note that when I test this with the latest release of OJB,
db-ojb-1.0.4.jar, this works fine. This indicates one of two things.
Either
I'm downloading and building the code from OJB_1_0_RELEASE
incorrectly or
a
bug was introduced into the OJB_1_0_RELEASE code. Please look into this
and
advise me further, thank you.
Regards,
Chris
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Tuesday, February
28, 2006 12:39 PM
To: OJB Users List
Subject: Re: OJB and the X-Files... :)
Hi Chris,
Christopher Lowe wrote:
Hi Armin,
I'm not using p6spy, but I removed all p6spy *.jars and
*.properties
files and still the same result.
Now I'm stumped. If it is reproducible in a separate test, please add
a issue in JIRA (with detailed pseudo code or a test case).
I'm going to have to dissect this portion
of my project and see if it can figure it out, this is really
nagging me.
I
will let you know.
It would be really helpful if you can reproduce this behavior with a
simple test case.
regards,
Armin
Regards,
Chris.
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Monday, February
27, 2006 10:55 PM
To: OJB Users List
Subject: Re: OJB and the X-Files... :)
Hi Christopher,
Christopher Lowe wrote:
Hi Armin,
Thanks for the tip about building the identity objects. I do agree
that
my
problem sounds similar to OJB-63. I'm using code downloaded from
the SVN
OJB_1_0_RELEASE branch as of 23rd of this month. Like what is
described
in
OJB-63 when I have
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG
I can see the correct sql being generated with the "clazz_" column in
the
ResultSet and hence the correct class is created. However when I turn
debugging off for this class, i.e I set it to
org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=WARN,
the super class is generated. I tried changing the loglevel for the
other
jdbc access querying and object materialization class entries in the
OJB-logging.properties file and only setting the loglevel to DEBUG for
SqlGeneratorDefaultImpl works. This is rather strange to me.
This is strange for me too. Did you enable p6spy while executing the
Query? If yes, please run your test again without p6spy.
regards,
Armin
Please advice,
thank you.
Regards,
Chris
-Original Message-
From: Armin Waibel [mailto:[EMAIL PROTECTED] Sent: Friday,
February 24, 2006 10:20 PM
To: OJB Users List
Subject: Re: OJB and the X-Files... :)
Hi Chris,
Christopher Lowe wrote:
Dear All,
I have a simple inheritance relationship between a Special and
ActivitySpecial. I'm using proxies throughout my project with the
cglib
proxy factory and indirection handler (I'm also using the broker
API).
I'm
performing a simple query to find an activity special as follows:
Special special = (Special) broker.getObjectByIdentity(new
Identity(new
Special(24), broker));
log.debug("Special: " + special);
It's recommended to use the service class IdentityFactory to build
the Identity and lookup persistent objects.
http://db.apache.org/ojb/docu/tutorials/pb-tutorial.html#Find+object+by+prim
ary+key
