Foreign key, Inverse foreign key & Extent class usage.
Hi all, I'm posting this question on behalf of Gautam, a user who can't post to the list directly because the Apache Anti Spam filter rejects his postings. cheers, Thomas How are the elements foreignkey, inverse-foreignkey and extent-class interpreted in the context of table-mapping strategies (Distinct table per class in hierarchy, Entire class hierarchy mapping to one table, Table per sub-class without FK and Table per sub-class with FK) and criteria queries ? I am a bit confused as it seems that both the foreignkey and inverse-foreignkey elements are mutually-exclusive to extent-class element. In the sense if foreignkey or inverse-foreignkey element(s) is/are present in the class-descriptor, the extent-class element(s) is/are not and vice-versa. Thanks and Regards, Gautam. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Expected Extent Behavior?
Hi Brian, Brian Latimer wrote: I have an Interface "I" It has implementing classes A, B, and C Classes B and C both extend class A and have a super reference to it. If use the following: when I search via getCollectionByQuery for instances of "I" then I get back instances of B and C with all their data and no A objects that duplicate the id's of these objects. (all instances of A are really either B or C, so this is what I want anyway) This is the expected behavior. Take care not to mix different inheritance strategies (is not supported). This case (table-per-subclass inheritance + interface extent) should work. Previously (OJB1.01 and less) I seem to recall getting back both an A and a B or and A and a C object for each id when I attempted queries of this sort. If instead I use: then I get null values for all the A class fields in the returned class B and C objects. Is this the expected behavior? Should the query be extent aware like this? In further OJB versions there was a bug related to the "table per subclass" inheritance (multiple joined tables bug) which only returns instances of the base class (see release-notes "known issues" section of previous versions). Think that the described behavior could be a side effect of this bug. regards, Armin I just thought I'd ask for clarification and if this was odd behavior point it out. thanks - 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]
Expected Extent Behavior?
I have an Interface "I" It has implementing classes A, B, and C Classes B and C both extend class A and have a super reference to it. If use the following: when I search via getCollectionByQuery for instances of "I" then I get back instances of B and C with all their data and no A objects that duplicate the id's of these objects. (all instances of A are really either B or C, so this is what I want anyway) Previously (OJB1.01 and less) I seem to recall getting back both an A and a B or and A and a C object for each id when I attempted queries of this sort. If instead I use: then I get null values for all the A class fields in the returned class B and C objects. Is this the expected behavior? Should the query be extent aware like this? I just thought I'd ask for clarification and if this was odd behavior point it out. thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
FW: Materialising the wrong type of object when prefetching relat ionships where related class is part of extent
Sorry -- should have gone to ojb-user! BTW -- the class that OJB thinks it should get the class descriptor for is the "first" (look in ChainingIterator for what this means) concrete sub-class in the extent. Many thanks Mark -Original Message- From: Mark Rowell Sent: 25 January 2005 12:25 To: 'ojb-dev@db.apache.org' Subject: Materialising the wrong type of object when prefetching relationships where related class is part of extent Hi I have loked on the ail list and found something similar to this. Certain times when I query a particular class That is not part of an extent but has (indirect) references to other objects that are part of an extent I get materialisation errors: org.apache.ojb.broker.metadata.MetadataException: IllegalAccess error setting field:rank in object:com.credittrade.instruments.derivatives.CreditDefaultSwap at org.apache.ojb.broker.accesslayer.BasePrefetcher.prefetchRelationship(BasePr efetcher.java:137) at org.apache.ojb.broker.core.QueryReferenceBroker.performRetrievalTasks(QueryR eferenceBroker.java:329) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:167) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:233) at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryRe ferenceBroker.java:253) at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(Persis tenceBrokerImpl.java:1217) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery( DelegatingPersistenceBroker.java:338) at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery( DelegatingPersistenceBroker.java:338) at com.credittrade.market.pc.options.OptionPriceLoader.fillOutReferenceLevels(O ptionPriceLoader.java:83) at com.credittrade.market.pc.PriceLoaderAbstractImpl.fillOutLastTraded(PriceLoa derAbstractImpl.java:313) at com.credittrade.market.pc.PriceLoaderAbstractImpl.initialLoad(PriceLoaderAbs tractImpl.java:57) at com.credittrade.market.pc.ClientPriceLoader$InitialLoad.execute(ClientPriceL oader.java:99) at com.credittrade.system.js.RPCTaskEntry.execute(RPCTaskEntry.java:63) at com.credittrade.system.js.TaskEntryProcessor.processEntry(TaskEntryProcessor .java:41) at com.credittrade.system.js.SpaceWorker$HandOff.run(SpaceWorker.java:230) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.ja va:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:6 75) at java.lang.Thread.run(Thread.java:595) After delving through the code even though OJB "knows" that I am trying to materialize an instance of a CreditDefaultSwap It is using the class/field descriptors for another type in the extent. The class I want (CreditDefaultSwap) Has a field converter for the field/column causing the problem but the other class does not & hence when OJB attempts to set The field into the object we get an IllegalAccessException as it is triyng to place an unconverted value into the field. All classes in the extent causing the problem are mapped onto a single table. The primary key is an INTEGER and is guarantted to be Unique (I have a UNIQUE PK constraint on the column) and I have queried the table for the relevant ID (for the problem object The primary key has the right ojbConcreteClass value in the table (CreditDefaultSwap). Has anyone come up against this before. I am using v1.0.1 & Java 5. The line numbers may not quite be correct as I have some print statement in place for debugging... Thanks Mark Rowell --- Mark Rowell Structured Credit Europe CreditTrade Limited No. 1 London Bridge, 6th Floor London SE1 9QL Tel +44 (0)20 7098 1653 http://www.credittrade.com CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2005. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should
RE: Criteria through extent (Was: Circular criteria)
> when resolving the path meeting.pdp.createdBy ojb looks for a
> collection- or
> reference-descriptor called 'meeting' and it uses the referenced
> class to reolve
> further path-segements 'pdp'. so if the class referenced by
> 'meeting' does
> not have a reference-descriptor named 'pdp' ojb is not able to
> resolve this
> reference.
So it doesnt automatically look for extent classes that have that property.
Initially it seemed to me that it ought to do this for you, but fair enough
though, as i guess there would be no 'right answer' if only some extents
have the field.
>
> there a two solutions right now:
> 1.) define a reference-descriptor named 'pdp' in your top-class (meeting)
Ok, but do i also need to define a fk field: pdpId? or can i leave that in
the extents? If i have to define the field, do i have to create a database
table for Meeting, or can that remain in the extents?
> 2.) use Criteri#addPathClass('pdp',Appraisal.class) as a hint
crit.addPathClass("meeting",Appraisal.class);
This works beautifully. I get the expected SQL. From the docs it suggests
that it will only look at the classes i hint, so other classes that extend
Meeting will be ignored. Is this right? This adds a desirable side effect,
as for these reports i am only interested in elements linked to an
Appraisal, no other extents.
For future reference, if i was specifying a deeper class (say Pdp) would i
use the path "meeting.pdp" or just "pdp"?
>
> hth
> jakob
Helped a LOT! Now i dont have to load thousands of useless records and
filter them with 'if' statements!
Thanks,
Daniel.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Criteria through extent (Was: Circular criteria)
hi daniel,
when resolving the path meeting.pdp.createdBy ojb looks for a collection- or
reference-descriptor called 'meeting' and it uses the referenced class to reolve
further path-segements 'pdp'. so if the class referenced by 'meeting' does
not have a reference-descriptor named 'pdp' ojb is not able to resolve this
reference.
there a two solutions right now:
1.) define a reference-descriptor named 'pdp' in your top-class (meeting)
2.) use Criteri#addPathClass('pdp',Appraisal.class) as a hint
hth
jakob
Daniel Perry schrieb:
It apprears that ojb doesnt like criteria at depths that go beyond an
extent.
My criteria is:
crit.addEqualTo("behaviourId", new Integer(id));
crit.addLessThan("rating", new Integer(1));
crit.addEqualTo("meeting.pdp.createdBy", new Integer(mid));
And this generates the following sql (shortened!):
SELECT ... FROM behaviourrating A0 INNER JOIN appraisal A1 ON
A0.meetingId=A1.id WHERE ((A0.behaviourId = '21') AND A0.rating < '1') AND
createdBy = '7'
As you can see, it generates the rating and behaviourId where clauses
properly. But the third clause doesnt work.
The table appraisal is an extent of meeting.
behaviourRating.meeting points to a Meeting, not an appraisal. At the
moment there is only one extent of meeting, but that will change in future,
so ditching meeting isnt an option.
Meeting doesnt have a reference to pdp, but appraisal does.
Should ojb handle this criteria? or should it say that as meeting doesnt
have a 'pdp.createdBy' defined, it will ignore it, even though all the
instanciable subclasses (Appraisal) do have! This would seem fair enough,
although a little annoying!
Could i add a reference (and associated id) for pdp, and employee to
Meeting, but still keep all subclasses in separate tables?
Thanks,
Daniel.
-
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]
Criteria through extent (Was: Circular criteria)
It apprears that ojb doesnt like criteria at depths that go beyond an
extent.
My criteria is:
crit.addEqualTo("behaviourId", new Integer(id));
crit.addLessThan("rating", new Integer(1));
crit.addEqualTo("meeting.pdp.createdBy", new Integer(mid));
And this generates the following sql (shortened!):
SELECT ... FROM behaviourrating A0 INNER JOIN appraisal A1 ON
A0.meetingId=A1.id WHERE ((A0.behaviourId = '21') AND A0.rating < '1') AND
createdBy = '7'
As you can see, it generates the rating and behaviourId where clauses
properly. But the third clause doesnt work.
The table appraisal is an extent of meeting.
behaviourRating.meeting points to a Meeting, not an appraisal. At the
moment there is only one extent of meeting, but that will change in future,
so ditching meeting isnt an option.
Meeting doesnt have a reference to pdp, but appraisal does.
Should ojb handle this criteria? or should it say that as meeting doesnt
have a 'pdp.createdBy' defined, it will ignore it, even though all the
instanciable subclasses (Appraisal) do have! This would seem fair enough,
although a little annoying!
Could i add a reference (and associated id) for pdp, and employee to
Meeting, but still keep all subclasses in separate tables?
Thanks,
Daniel.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Joose Vettenranta wrote: I solved it so, that I made 3 classes abstarct A B extends A C extends A and in code I call B or C not A. But still, B and C can't use same table name. Oh well, can't have everything. Problem is that now I have to change every class to use C instead of using A or B. What I would like to do like this: A B extends A and use B where B's extra stuff is needed and A where it's not needed. This way I can change just few files to use B and use A elsewhere. Now I have to change everything to use B. This should work when you use the ojbConcreteClass strategy. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Hi, it seems that when I try to get Child it also get's SuperChild.. even though I haven't said that it should get superchild. All I want is to get just Child not superCHild.. Perhaps it's not possible to get like this? You'll need to add a field called 'ojbConcreteClass' so that OJB knows which class to instantiate. Or you can super-references (in which case you don't need to duplicate the fields from Child in SuperChild in the repository file). See here for details on these strategies: http://db.apache.org/ojb/docu/guides/advanced- technique.html#Mapping+Inheritance+Hierarchies I solved it so, that I made 3 classes abstarct A B extends A C extends A and in code I call B or C not A. But still, B and C can't use same table name. Oh well, can't have everything. Problem is that now I have to change every class to use C instead of using A or B. What I would like to do like this: A B extends A and use B where B's extra stuff is needed and A where it's not needed. This way I can change just few files to use B and use A elsewhere. Now I have to change everything to use B. Also I don't know whether two connections on the same database works. You might run into problems with the cache. You should definitly have a look at the different cache implementations provided with OJB: Yes, this was a problem and solved in CVS. - Joose -- "Always remember that you are unique, just like everyone else!" * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Joose Vettenranta wrote: Hi, it seems that when I try to get Child it also get's SuperChild.. even though I haven't said that it should get superchild. All I want is to get just Child not superCHild.. Perhaps it's not possible to get like this? You'll need to add a field called 'ojbConcreteClass' so that OJB knows which class to instantiate. Or you can super-references (in which case you don't need to duplicate the fields from Child in SuperChild in the repository file). See here for details on these strategies: http://db.apache.org/ojb/docu/guides/advanced-technique.html#Mapping+Inheritance+Hierarchies Also I don't know whether two connections on the same database works. You might run into problems with the cache. You should definitly have a look at the different cache implementations provided with OJB: http://db.apache.org/ojb/docu/guides/objectcache.html Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Hi, it seems that when I try to get Child it also get's SuperChild.. even though I haven't said that it should get superchild. All I want is to get just Child not superCHild.. Perhaps it's not possible to get like this? How about if I do Child interface and SuperChild implements Child and ChildImpl implements Child could it work then? - Joose 13.8.2004 kello 16:50, Thomas Dudziak kirjoitti: Joose Vettenranta wrote: I did this and it did not work. I get this: java.lang.NullPointerException ... java.lang.VerifyError: Class net.vettenranta.super.Child overrides final method jdoReplaceFlags.()V at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:256) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:30) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:98) at org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(Repos it oryXmlHandler.java:199) . using: 1.0rc6 Hmm, can't help you with the JDO stuff. You should post this error again (with the URL to your doc/tutorial) in a new thread with JDO in the message label (to attract the JDO experts). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "Always remember that you are unique, just like everyone else!" * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Hi, I actually solved that JDO, problem but now my problems continue... I made that superchild and child has same table name.. superchild uses different connection than connection using child object. But when I try to fetch Child, it actually tries to get SuperChild and not Child -> SQL-error. Is this feature or have I done something wrong? - Joose 13.8.2004 kello 16:50, Thomas Dudziak kirjoitti: Joose Vettenranta wrote: I did this and it did not work. I get this: java.lang.NullPointerException ... java.lang.VerifyError: Class net.vettenranta.super.Child overrides final method jdoReplaceFlags.()V at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:256) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:30) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:98) at org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(Repos it oryXmlHandler.java:199) . using: 1.0rc6 Hmm, can't help you with the JDO stuff. You should post this error again (with the URL to your doc/tutorial) in a new thread with JDO in the message label (to attract the JDO experts). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- "Always remember that you are unique, just like everyone else!" * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Joose Vettenranta wrote: I did this and it did not work. I get this: java.lang.NullPointerException ... java.lang.VerifyError: Class net.vettenranta.super.Child overrides final method jdoReplaceFlags.()V at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:256) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:30) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:98) at org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(Reposit oryXmlHandler.java:199) . using: 1.0rc6 Hmm, can't help you with the JDO stuff. You should post this error again (with the URL to your doc/tutorial) in a new thread with JDO in the message label (to attract the JDO experts). Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
You have to specify the extent-class as the first sub-tag of class-descriptor (see http://db.apache.org/ojb/docu/guides/repository.html#class-descriptor for details). Also, you have to duplicate all fields/references/collections from Child in SuperChild, currently they are not automatically 'inherited' in the descriptor of the sub class. I did this and it did not work. I get this: java.lang.NullPointerException ... java.lang.VerifyError: Class net.vettenranta.super.Child overrides final method jdoReplaceFlags.()V at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:256) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:30) at org.apache.ojb.broker.util.ClassHelper.getClass(ClassHelper.java:98) at org.apache.ojb.broker.metadata.RepositoryXmlHandler.startElement(Reposit oryXmlHandler.java:199) . using: 1.0rc6 I would recommend that you use the OJB and JDO Xdoclet modules (OJB module is part of OJB, the JDO module can be downloaded from http://xdoclet.sourceforge.net/xdoclet/index.html) to generate these two files, they will make things a lot easier for you. Have to look into it. - Joose -- "Always remember that you are unique, just like everyone else!" * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Joose Vettenranta wrote: Hi, everything else except SuperChild is in http://joose.iki.fi/ojb/ SuperChild.java I already pasted. repository.xml: You have to specify the extent-class as the first sub-tag of class-descriptor (see http://db.apache.org/ojb/docu/guides/repository.html#class-descriptor for details). Also, you have to duplicate all fields/references/collections from Child in SuperChild, currently they are not automatically 'inherited' in the descriptor of the sub class. I would recommend that you use the OJB and JDO Xdoclet modules (OJB module is part of OJB, the JDO module can be downloaded from http://xdoclet.sourceforge.net/xdoclet/index.html) to generate these two files, they will make things a lot easier for you. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Hi, everything else except SuperChild is in http://joose.iki.fi/ojb/ SuperChild.java I already pasted. repository.xml: packages.jdo about SuperChild I already posted. - Joose -- "Always remember that you are unique, just like everyone else!" * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Joose Vettenranta wrote: I have Child in jdo and it works ok but Superchild I told what kind it is: Could you post those two classes (at least with the fields/bean properties that you declared in the repository file) and the jdo and repository file ? Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
12.8.2004 kello 15:03, Thomas Dudziak kirjoitti: Joose Vettenranta wrote: Clarifying myself: I want to have just one table in SQL called child. And software eather uses Child or SuperChild (same table name in both). I tried moving (repository.xml) extent-class to superclass, but didn't help. I don't know about JDO, but you probably have to specify both Child and SuperChild in both the jdo file and the repository file. I have Child in jdo and it works ok but Superchild I told what kind it is: - Joose -- "Always remember that you are unique, just like everyone else!" * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Joose Vettenranta wrote: Clarifying myself: I want to have just one table in SQL called child. And software eather uses Child or SuperChild (same table name in both). I tried moving (repository.xml) extent-class to superclass, but didn't help. I don't know about JDO, but you probably have to specify both Child and SuperChild in both the jdo file and the repository file. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Clarifying myself:
I want to have just one table in SQL called child. And software eather
uses Child or SuperChild (same table name in both).
I tried moving (repository.xml) extent-class to superclass, but didn't
help.
- Joose
12.8.2004 kello 14:50, Joose Vettenranta kirjoitti:
Hi,
I'm having problems on using extent-class and extending java-classes..
I have like this:
class SuperChild extends Child {
private int age;
// getters and setters
}
class Child {
private int id;
private Parent parent;
private String name;
}
and in jdo-file I have:
and it goes OK enhancing.
repository.xml:
and result is:
org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException:
Can not init Identity for given object
[EMAIL PROTECTED]
What could be wrong?
Thanks, Joose
--
"Always remember that you are unique, just like everyone else!"
* http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 *
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
"Always remember that you are unique, just like everyone else!"
* http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 *
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent problem
Joose Vettenranta wrote:
Hi,
I'm having problems on using extent-class and extending java-classes..
I have like this:
class SuperChild extends Child {
private int age;
// getters and setters
}
class Child {
private int id;
private Parent parent;
private String name;
}
and in jdo-file I have:
and it goes OK enhancing.
repository.xml:
and result is:
org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException:
Can not init Identity for given object [EMAIL PROTECTED]
What could be wrong?
The extent-class tag is a bit counter-intuitive because it specifies the
opposite direction of the Java extends/implements. So if you put
into the class descriptor for Child, you should be fine.
Tom
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
extent problem
Hi,
I'm having problems on using extent-class and extending java-classes..
I have like this:
class SuperChild extends Child {
private int age;
// getters and setters
}
class Child {
private int id;
private Parent parent;
private String name;
}
and in jdo-file I have:
and it goes OK enhancing.
repository.xml:
and result is:
org.apache.ojb.broker.metadata.ClassNotPersistenceCapableException: Can
not init Identity for given object [EMAIL PROTECTED]
What could be wrong?
Thanks, Joose
--
"Always remember that you are unique, just like everyone else!"
* http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 *
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
about extent class
Hi, I was looking at extent-class and what I didn't get was how it really works.. So here is an exmaple: I have 1:n relation (parent:childs).. and I want to create superchild.. like 1:n (parent:superchild) is it possible to do just in SQL: CREATE TABLE super_child ( id integer, name varchar(50), age integer, parent_id integer, PRIMARY KEY(id), FOREIGN KEY (parent_id) REFERENCES parent(id)); and in repository.xml just this: and of course class-descriptor for Child would have (id, name and parent field-descriptors and reference-descriptors). Or do I just have to copy&paste whole child to superChild? Thanks, Joose -- "Always remember that you are unique, just like everyone else!" * http://iki.fi/joose/ * [EMAIL PROTECTED] * +358 44 561 0270 * - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wrong SQL generated when use path expression for extent with Multiple Joined Tables
I solved and post the patch to commit, please the solution in http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=1750208 Clóvis Wichoski wrote: Hi, I'm getting wrong results when executing a Query with Criteria that uses path expression for extent with Multiple Joined Tables: The QueryByCriteria from class myproject.User where [myCompany.shortcut = COMPANYX, [login = UserX]] The expected result is that returns only the User of COMPANYX with login UserX, but this results in ALL login equals UserX, the OR part in SQL generate the wrong result, because the field shortcut exists only in superclass Person In list archives I found some messages that may make sense for this error: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=7587 maybe that says "..if no field is found the name from the criteria is used.." but for the multiple joined extend this must be false, or my mappings are wrong? and maybe this message started this trouble with multiple joined tables: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=612081 Follow the part of trace I'm getting here: ... [org.apache.ojb.broker.core.PersistenceBrokerImpl] DEBUG: Creating RsIterator for class [myproject.User] [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class myproject.User where [myCompany.shortcut = COMPANYX, [login = UserX]] [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: Result of getTableAlias(): PERSON A1 [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: SQL:SELECT A0.VERSION,A0.STATUS,A0.PASSWORD,A0.LOGIN,A0.OID,A0.MY_COMPANY,A0.MY_EMPLOYEE FROM USER A0,PERSON A1,EMPLOYEE A1E0,COMPANY A1E1 WHERE A0.MY_COMPANY=A1.OID(+) AND A0.MY_COMPANY=A1E0.OID(+) AND A0.MY_COMPANY=A1E1.OID(+) AND (( (A1.SHORTCUT = ? OR shortcut = ? OR shortcut = ?)) AND (A0.LOGIN = ?)) ... but the correct SQL is: SELECT A0.VERSION,A0.STATUS,A0.PASSWORD,A0.LOGIN,A0.OID,A0.MY_COMPANY,A0.MY_EMPLOYEE FROM USER A0,PERSON A1,EMPLOYEE A1E0,COMPANY A1E1 WHERE A0.MY_COMPANY=A1.OID(+) AND A0.MY_COMPANY=A1E0.OID(+) AND A0.MY_COMPANY=A1E1.OID(+) AND (( (A1.SHORTCUT = ? ) AND (A0.LOGIN = ?)) I'm using a compiled CVS checkout of version 1.0, with a SapDB database. TIA Clóvis - 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]
wrong SQL generated when use path expression for extent with Multiple Joined Tables
Hi, I'm getting wrong results when executing a Query with Criteria that uses path expression for extent with Multiple Joined Tables: The QueryByCriteria from class myproject.User where [myCompany.shortcut = COMPANYX, [login = UserX]] The expected result is that returns only the User of COMPANYX with login UserX, but this results in ALL login equals UserX, the OR part in SQL generate the wrong result, because the field shortcut exists only in superclass Person In list archives I found some messages that may make sense for this error: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=7587 maybe that says "..if no field is found the name from the criteria is used.." but for the multiple joined extend this must be false, or my mappings are wrong? and maybe this message started this trouble with multiple joined tables: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=612081 Follow the part of trace I'm getting here: ... [org.apache.ojb.broker.core.PersistenceBrokerImpl] DEBUG: Creating RsIterator for class [myproject.User] [org.apache.ojb.broker.accesslayer.JdbcAccessImpl] DEBUG: executeQuery : QueryByCriteria from class myproject.User where [myCompany.shortcut = COMPANYX, [login = UserX]] [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.accesslayer.sql.SqlQueryStatement$TableAlias] DEBUG: TableAlias(): using hints ? false [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: Result of getTableAlias(): PERSON A1 [org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl] DEBUG: SQL:SELECT A0.VERSION,A0.STATUS,A0.PASSWORD,A0.LOGIN,A0.OID,A0.MY_COMPANY,A0.MY_EMPLOYEE FROM USER A0,PERSON A1,EMPLOYEE A1E0,COMPANY A1E1 WHERE A0.MY_COMPANY=A1.OID(+) AND A0.MY_COMPANY=A1E0.OID(+) AND A0.MY_COMPANY=A1E1.OID(+) AND (( (A1.SHORTCUT = ? OR shortcut = ? OR shortcut = ?)) AND (A0.LOGIN = ?)) ... but the correct SQL is: SELECT A0.VERSION,A0.STATUS,A0.PASSWORD,A0.LOGIN,A0.OID,A0.MY_COMPANY,A0.MY_EMPLOYEE FROM USER A0,PERSON A1,EMPLOYEE A1E0,COMPANY A1E1 WHERE A0.MY_COMPANY=A1.OID(+) AND A0.MY_COMPANY=A1E0.OID(+) AND A0.MY_COMPANY=A1E1.OID(+) AND (( (A1.SHORTCUT = ? ) AND (A0.LOGIN = ?)) I'm using a compiled CVS checkout of version 1.0, with a SapDB database. TIA Clóvis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Interaction of Extent and Super
hi gary, an extent defines subclasses in the repository. these subclasses may reside in their own tables or they may share a common table. each of the subclasses is self-contained (it's mapped on one table only). the super-reference is used to split up a class on multiple tables. each of the tables is mapped to a super-class. hth jakob Gary wrote: Any takers on this one? Thanks to all for any help... Gary I have read the advanced O/R mapping document, but am still a bit confused about the meanings, usage and interaction of extents and the "super" keyword. Can someone give me a quick explanation? Thanks, Gary __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ - 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: Interaction of Extent and Super
Any takers on this one? Thanks to all for any help... Gary > I have read the advanced O/R mapping document, but am > still a bit confused about the meanings, usage and > interaction of extents and the "super" keyword. Can > someone give me a quick explanation? > Thanks, Gary __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Interaction of Extent and Super
I have read the advanced O/R mapping document, but am still a bit confused about the meanings, usage and interaction of extents and the "super" keyword. Can someone give me a quick explanation? Thanks, Gary __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent mapping (was: another JOIN question)
Hi again, OK, missed that change, I guess when mapping on multiple tables began to be supported (this wasn't the case when I started using OJB). But is it also valid repository syntax for mapping in the "All Classes on the Same Table" model? Phil Charles N. Harvey III wrote: Phil, This is where I found it: http://db.apache.org/ojb/tutorial3.html#Mapping%20Classes%20on%20Multiple%20Joined%20Tables One major subsection below Extents and Polymorphism. "Mapping Inheritance Heirarchies" is the section it is in. Charlie Phil Warrick wrote: Hi all, While reading this thread, I came across something that looks like an improved way to map extents. (reference-descriptor name - "super" etc.) Have I been sleeping while this development took place? This seems to be undocumented. Phil - 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: extent mapping (was: another JOIN question)
WOW! Are you saying name="super" works Or, just a suggestion. This is some good s! From: Phil Warrick <[EMAIL PROTECTED]> Reply-To: "OJB Users List" <[EMAIL PROTECTED]> To: OJB Users List <[EMAIL PROTECTED]> Subject: extent mapping (was: another JOIN question) Date: Wed, 12 May 2004 11:29:31 -0400 Hi all, While reading this thread, I came across something that looks like an improved way to map extents. (reference-descriptor name - "super" etc.) Have I been sleeping while this development took place? This seems to be undocumented. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Stop worrying about overloading your inbox - get MSN Hotmail Extra Storage! http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extent mapping (was: another JOIN question)
Phil, This is where I found it: http://db.apache.org/ojb/tutorial3.html#Mapping%20Classes%20on%20Multiple%20Joined%20Tables One major subsection below Extents and Polymorphism. "Mapping Inheritance Heirarchies" is the section it is in. Charlie Phil Warrick wrote: Hi all, While reading this thread, I came across something that looks like an improved way to map extents. (reference-descriptor name - "super" etc.) Have I been sleeping while this development took place? This seems to be undocumented. Phil - 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]
extent mapping (was: another JOIN question)
Hi all, While reading this thread, I came across something that looks like an improved way to map extents. (reference-descriptor name - "super" etc.) Have I been sleeping while this development took place? This seems to be undocumented. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent problem with ODMG
hi steve, i'm happy it solved your problem. you can define relationships or fields in any class-descriptor, abstract or concrete. in your case you need it in the abstract because of A pointing to S. but if you would query for all B or C pointing to a D (ie. D.name) then the definition in concrete B and D are used. i admit it would be easier if ojb would support inheritence of descriptors. but that's another story. jakob Steve Clark wrote: This did indeed solve the problem. In summary, repository.xml has: - Foreign key field defined in subclasses only - Relationship defined in subclasses and in superclass And in Java the relationship accessors are defined in the superclass only. I didn't even know that one could put fields or relationships in the superclass in repository.xml. Thanks for pointing this out, Jakob! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent problem with ODMG
This did indeed solve the problem. In summary, repository.xml has:
- Foreign key field defined in subclasses only
- Relationship defined in subclasses and in superclass
And in Java the relationship accessors are defined in the superclass
only.
I didn't even know that one could put fields or relationships in the
superclass in repository.xml. Thanks for pointing this out, Jakob!
--
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291
>>>>> Jakob Braeuchi writes:
Jakob> hi,
Jakob> you'll have to define the relationship to D in the abstract
Jakob> S as well as in the concrete B and C. it has to be defined
Jakob> in S because when navigation from A the descriptor of class
Jakob> S is used to resolve the relationship.
Jakob> i tried this meaningless query :
Jakob> Criteria crit = new Criteria();
Jakob> crit.addLike("allArticlesInGroup.productGroup.groupName",
Jakob> "B%"); QueryByCriteria q =
Jakob> ueryFactory.newQuery(ProductGroupWithAbstractArticles.class,
Jakob> crit, true);
Jakob> if i do not define a relationship in class InterfaceArticle
Jakob> to class ProductGroup the SQL fails. after adding
Jakob> ...
Jakob> class="org.apache.ojb.broker.InterfaceArticle">
Jakob>class-ref="org.apache.ojb.broker.Article" />
Jakob>class-ref="org.apache.ojb.broker.BookArticle" />
Jakob>class-ref="org.apache.ojb.broker.CdArticle" />
Jakob> name="productGroup"
Jakob> class-ref="org.apache.ojb.broker.ProductGroup"
>>
Jakob> this is the reference to an
Jakob> articles
Jakob> productgroup
Jakob>
Jakob> attribute-value="red" />
Jakob> attribute-value="tiny" />
Jakob>
Jakob>
Jakob> ...
Jakob> hth jakob
> hi charles, steve,
>
> i do not think that my fix is related to this problem. i propose to move
> the definition of the relationship to the concrete classes.
>
> jakob
>
> Charles Anthony wrote:
>
>> Hi,
>>
>> I have a hunch - quite possibly misplaced - that this may have
>> something to
>> do the bug I reported in the thhread entitled.
>> "Criteria.setClassPath - the saga continues"
>>
>> Although you are using an ODMG query, when the query is parsed, it does
>> generate a standard QueryByCriteria. QueryByCriteria was getting the
>> wrong
>> class descriptor when paths of > 1 sement were used. This would lead
>> to the
>> attribute name being passed to the query, as opposed to the column name.
>>
>> Jakob fixed this in CVS last night.
>>
>> This May Be A Red Herring.
>>
>> Cheers,
>>
>> Charles.
>>
>>
>>> -Original Message-
>>> From: Steve Clark [mailto:[EMAIL PROTECTED]
>>> Sent: 03 March 2004 19:56
>>> To: OJB Users List
>>> Subject: Re: Extent problem with ODMG
>>>
>>>
>>> I'm still having this problem, so I'm going to try again.
>>>
>>> Using ODMG, RC5, Oracle 9i.
>>>
>>> Summary:
>>>- Class A has a 1-to-1 relationship 'abs' to an abstract
>>> superclass S
>>>- Class S has concrete subclasses B and C
>>>- Classes B and C share a common relationship 'com' to another
>>> class D; this relationship is defined in the superclass S
>>>- Class D has a property 'p'
>>>- A, B, C, and D map to distinct tables
>>>
>>> I am trying to retrieve all A's which have a given value for 'p' in
>>> the D associated with the related B or C (whichever one it is). So:
>>>
>>>select x from A where A.abs.com.p = ?
>>>
>>> A.abs has type S, the abstract superclass; A.abs.com has type D. This
>>> means that the query needs to generate some sort of interesting join
>>> to check for both possible paths to D (via B or C), knowing that
>>> either B or C will have exactly one row satisfying the join
>>> condition(s). In pseudocode:
>>>
>>>select x from A where
>>>if A.abs instanceof B then ((B) A.abs).com.p = ?
>>>else if A.abs instanceof C then ((C) A.abs).com.p = ?
>>>
>>> Should I expect this to work? The SQL
Re: Extent problem with ODMG
hi,
you'll have to define the relationship to D in the abstract S as well as in the
concrete B and C. it has to be defined in S because when navigation from A the
descriptor of class S is used to resolve the relationship.
i tried this meaningless query :
Criteria crit = new Criteria();
crit.addLike("allArticlesInGroup.productGroup.groupName", "B%");
QueryByCriteria q = ueryFactory.newQuery(ProductGroupWithAbstractArticles.class,
crit, true);
if i do not define a relationship in class InterfaceArticle to class
ProductGroup the SQL fails. after adding
...
name="productGroup"
class-ref="org.apache.ojb.broker.ProductGroup"
>
this is the reference to an articles
productgroup
...
hth
jakob
Jakob Braeuchi wrote:
hi charles, steve,
i do not think that my fix is related to this problem. i propose to move
the definition of the relationship to the concrete classes.
jakob
Charles Anthony wrote:
Hi,
I have a hunch - quite possibly misplaced - that this may have
something to
do the bug I reported in the thhread entitled.
"Criteria.setClassPath - the saga continues"
Although you are using an ODMG query, when the query is parsed, it does
generate a standard QueryByCriteria. QueryByCriteria was getting the
wrong
class descriptor when paths of > 1 sement were used. This would lead
to the
attribute name being passed to the query, as opposed to the column name.
Jakob fixed this in CVS last night.
This May Be A Red Herring.
Cheers,
Charles.
-Original Message-
From: Steve Clark [mailto:[EMAIL PROTECTED]
Sent: 03 March 2004 19:56
To: OJB Users List
Subject: Re: Extent problem with ODMG
I'm still having this problem, so I'm going to try again.
Using ODMG, RC5, Oracle 9i.
Summary:
- Class A has a 1-to-1 relationship 'abs' to an abstract
superclass S
- Class S has concrete subclasses B and C
- Classes B and C share a common relationship 'com' to another
class D; this relationship is defined in the superclass S
- Class D has a property 'p'
- A, B, C, and D map to distinct tables
I am trying to retrieve all A's which have a given value for 'p' in
the D associated with the related B or C (whichever one it is). So:
select x from A where A.abs.com.p = ?
A.abs has type S, the abstract superclass; A.abs.com has type D. This
means that the query needs to generate some sort of interesting join
to check for both possible paths to D (via B or C), knowing that
either B or C will have exactly one row satisfying the join
condition(s). In pseudocode:
select x from A where
if A.abs instanceof B then ((B) A.abs).com.p = ?
else if A.abs instanceof C then ((C) A.abs).com.p = ?
Should I expect this to work? The SQL query which is being generated
is not only incorrect but invalid: OJB does not rewrite 'p', and in
fact does not even mention D at all. I assume this has to do with
the fact that the repository doesn't record the presence of the
relationship 'com' in the abstract superclass, but only in the
subclasses. Queries starting from B or C and following the 'com'
relationship work fine. Am I out of luck, or is there some way I can
get a working query out of this?
thanks for any insights,
Steve Clark
Technology Applications Team
Natural Resources Research Center/USGS
[EMAIL PROTECTED]
(970)226-9291
PS: Original message below. Name mappings:
A = PartnerImpl
B = SubSiteImpl
C = TechAssistImpl
D = SiteImpl
S = AccomplishmentImpl
abs = accomp
com = site
p = habTypeCode
sc> I'm having a problem with extents in ODMG. OJB is generating
sc> incorrect (and, in fact, invalid) SQL for my OQL query. I'm
sc> using RC5.
sc> My data model consists of Sites, which have collections of
sc> each of two kinds of Accomplishments (SubSites and
sc> TechAssists). An Accomplishment has a collection of Partners.
sc> In the reverse direction, each Partner is associated with
sc> exactly one Accomplishment (either a SubSite or a TechAssist),
sc> and an Accomplishment knows about its parent Site. My
sc> repository looks like this:
sc>
sc> class="gov.doi.habits.dataobjects.SiteImpl"
sc> table="SITE_DETAIL" proxy="dynamic">
sc> name="siteKey" column="SITE_KEY" jdbc-type="INTEGER"
sc> primarykey="true" autoincrement="true"/>
sc> name="habTypeCode" column="HAB_TYPE_CODE"
sc> jdbc-type="INTEGER" />
sc>
sc> name="subSites"
sc> element-class-ref="gov.doi.habits.dataobjects.SubSiteImpl"
sc>
Re: Extent problem with ODMG
hi charles, steve, i do not think that my fix is related to this problem. i propose to move the definition of the relationship to the concrete classes. jakob Charles Anthony wrote: Hi, I have a hunch - quite possibly misplaced - that this may have something to do the bug I reported in the thhread entitled. "Criteria.setClassPath - the saga continues" Although you are using an ODMG query, when the query is parsed, it does generate a standard QueryByCriteria. QueryByCriteria was getting the wrong class descriptor when paths of > 1 sement were used. This would lead to the attribute name being passed to the query, as opposed to the column name. Jakob fixed this in CVS last night. This May Be A Red Herring. Cheers, Charles. -Original Message- From: Steve Clark [mailto:[EMAIL PROTECTED] Sent: 03 March 2004 19:56 To: OJB Users List Subject: Re: Extent problem with ODMG I'm still having this problem, so I'm going to try again. Using ODMG, RC5, Oracle 9i. Summary: - Class A has a 1-to-1 relationship 'abs' to an abstract superclass S - Class S has concrete subclasses B and C - Classes B and C share a common relationship 'com' to another class D; this relationship is defined in the superclass S - Class D has a property 'p' - A, B, C, and D map to distinct tables I am trying to retrieve all A's which have a given value for 'p' in the D associated with the related B or C (whichever one it is). So: select x from A where A.abs.com.p = ? A.abs has type S, the abstract superclass; A.abs.com has type D. This means that the query needs to generate some sort of interesting join to check for both possible paths to D (via B or C), knowing that either B or C will have exactly one row satisfying the join condition(s). In pseudocode: select x from A where if A.abs instanceof B then ((B) A.abs).com.p = ? else if A.abs instanceof C then ((C) A.abs).com.p = ? Should I expect this to work? The SQL query which is being generated is not only incorrect but invalid: OJB does not rewrite 'p', and in fact does not even mention D at all. I assume this has to do with the fact that the repository doesn't record the presence of the relationship 'com' in the abstract superclass, but only in the subclasses. Queries starting from B or C and following the 'com' relationship work fine. Am I out of luck, or is there some way I can get a working query out of this? thanks for any insights, Steve Clark Technology Applications Team Natural Resources Research Center/USGS [EMAIL PROTECTED] (970)226-9291 PS: Original message below. Name mappings: A = PartnerImpl B = SubSiteImpl C = TechAssistImpl D = SiteImpl S = AccomplishmentImpl abs = accomp com = site p = habTypeCode sc> I'm having a problem with extents in ODMG. OJB is generating sc> incorrect (and, in fact, invalid) SQL for my OQL query. I'm sc> using RC5. sc> My data model consists of Sites, which have collections of sc> each of two kinds of Accomplishments (SubSites and sc> TechAssists). An Accomplishment has a collection of Partners. sc> In the reverse direction, each Partner is associated with sc> exactly one Accomplishment (either a SubSite or a TechAssist), sc> and an Accomplishment knows about its parent Site. My sc> repository looks like this: sc> sc> class="gov.doi.habits.dataobjects.SiteImpl" sc> table="SITE_DETAIL" proxy="dynamic"> sc> name="siteKey" column="SITE_KEY" jdbc-type="INTEGER" sc> primarykey="true" autoincrement="true"/> sc> name="habTypeCode" column="HAB_TYPE_CODE" sc> jdbc-type="INTEGER" /> sc> sc> name="subSites" sc> element-class-ref="gov.doi.habits.dataobjects.SubSiteImpl" sc> collection-class="org.apache.ojb.broker.util.collections.Manag eableArrayList"> sc> sc> sc> sc> name="techAssists" sc> element-class-ref="gov.doi.habits.dataobjects.TechAssistImpl" sc> collection-class="org.apache.ojb.broker.util.collections.Manag eableArrayList"> sc> sc> sc> sc> sc> class="gov.doi.habits.dataobjects.AccomplishmentImpl" > sc> class-ref="gov.doi.habits.dataobjects.SubSiteImpl" /> sc> class-ref="gov.doi.habits.dataobjects.AssistImpl" /> sc> sc> sc> class="gov.doi.habits.dataobjects.SubSiteImpl" sc> table="SUB_SITE_DETAIL" proxy="dynamic"> sc>
RE: Extent problem with ODMG
Have you tried duplicating the collection descriptor in the repository for each extent? I don't believe that OJB supports collection or reference descriptor inheritance. Wally -Original Message- From: Steve Clark [mailto:[EMAIL PROTECTED] Sent: Thursday, March 04, 2004 11:24 AM To: OJB Users List Subject: RE: Extent problem with ODMG Charles, Thanks for the suggestion. I have tried CVS HEAD and I still get the same incorrect behavior. I'm still unclear whether OJB even *expects* to get this query right, because it doesn't know that 'com' is actually a property of the abstract superclass. That is, when it follows the 'abs' relationship, it reaches a class-descriptor which has no field-descriptors, and indeed it seems to at least partially stop interpreting the path at this point. But this class-descriptor does have two extent-classes which each have identical 'com' relationships leading to a class which does have the 'p' property. -- Steve Clark Technology Applications Team Natural Resources Research Center/USGS [EMAIL PROTECTED] (970)226-9291 >>>>> Charles Anthony writes: Charles> I have a hunch - quite possibly misplaced - that this may Charles> have something to do the bug I reported in the thhread Charles> entitled. "Criteria.setClassPath - the saga continues" Charles> Although you are using an ODMG query, when the query is Charles> parsed, it does generate a standard Charles> QueryByCriteria. QueryByCriteria was getting the wrong Charles> class descriptor when paths of > 1 sement were used. This Charles> would lead to the attribute name being passed to the Charles> query, as opposed to the column name. Charles> Jakob fixed this in CVS last night. > -Original Message- > From: Steve Clark [mailto:[EMAIL PROTECTED] > Sent: 03 March 2004 19:56 > To: OJB Users List > Subject: Re: Extent problem with ODMG > > > I'm still having this problem, so I'm going to try again. > > Using ODMG, RC5, Oracle 9i. > > Summary: > - Class A has a 1-to-1 relationship 'abs' to an abstract > superclass S > - Class S has concrete subclasses B and C > - Classes B and C share a common relationship 'com' to another > class D; this relationship is defined in the superclass S > - Class D has a property 'p' > - A, B, C, and D map to distinct tables > > I am trying to retrieve all A's which have a given value for 'p' in > the D associated with the related B or C (whichever one it is). So: > > select x from A where A.abs.com.p = ? > > A.abs has type S, the abstract superclass; A.abs.com has type D. This > means that the query needs to generate some sort of interesting join > to check for both possible paths to D (via B or C), knowing that > either B or C will have exactly one row satisfying the join > condition(s). In pseudocode: > > select x from A where > if A.abs instanceof B then ((B) A.abs).com.p = ? > else if A.abs instanceof C then ((C) A.abs).com.p = ? > > Should I expect this to work? The SQL query which is being generated > is not only incorrect but invalid: OJB does not rewrite 'p', and in > fact does not even mention D at all. I assume this has to do with the > fact that the repository doesn't record the presence of the > relationship 'com' in the abstract superclass, but only in the > subclasses. Queries starting from B or C and following the 'com' > relationship work fine. Am I out of luck, or is there some way I can > get a working query out of this? > > thanks for any insights, > Steve Clark > Technology Applications Team > Natural Resources Research Center/USGS [EMAIL PROTECTED] > (970)226-9291 > > PS: Original message below. Name mappings: > > A = PartnerImpl > B = SubSiteImpl > C = TechAssistImpl > D = SiteImpl > S = AccomplishmentImpl > > abs = accomp > com = site > p = habTypeCode > > sc> I'm having a problem with extents in ODMG. OJB is generating > sc> incorrect (and, in fact, invalid) SQL for my OQL query. I'm > sc> using RC5. > > sc> My data model consists of Sites, which have collections of > sc> each of two kinds of Accomplishments (SubSites and > sc> TechAssists). An Accomplishment has a collection of Partners. > sc> In the reverse direction, each Partner is associated with > sc> exactly one Accomplishment (either a SubSite or a TechAssist), > sc> and an Accomplishment knows about its parent Site. My > sc> repository looks like this: > >
RE: Extent problem with ODMG
Charles, Thanks for the suggestion. I have tried CVS HEAD and I still get the same incorrect behavior. I'm still unclear whether OJB even *expects* to get this query right, because it doesn't know that 'com' is actually a property of the abstract superclass. That is, when it follows the 'abs' relationship, it reaches a class-descriptor which has no field-descriptors, and indeed it seems to at least partially stop interpreting the path at this point. But this class-descriptor does have two extent-classes which each have identical 'com' relationships leading to a class which does have the 'p' property. -- Steve Clark Technology Applications Team Natural Resources Research Center/USGS [EMAIL PROTECTED] (970)226-9291 >>>>> Charles Anthony writes: Charles> I have a hunch - quite possibly misplaced - that this may Charles> have something to do the bug I reported in the thhread Charles> entitled. "Criteria.setClassPath - the saga continues" Charles> Although you are using an ODMG query, when the query is Charles> parsed, it does generate a standard Charles> QueryByCriteria. QueryByCriteria was getting the wrong Charles> class descriptor when paths of > 1 sement were used. This Charles> would lead to the attribute name being passed to the Charles> query, as opposed to the column name. Charles> Jakob fixed this in CVS last night. > -Original Message- > From: Steve Clark [mailto:[EMAIL PROTECTED] > Sent: 03 March 2004 19:56 > To: OJB Users List > Subject: Re: Extent problem with ODMG > > > I'm still having this problem, so I'm going to try again. > > Using ODMG, RC5, Oracle 9i. > > Summary: > - Class A has a 1-to-1 relationship 'abs' to an abstract > superclass S > - Class S has concrete subclasses B and C > - Classes B and C share a common relationship 'com' to another > class D; this relationship is defined in the superclass S > - Class D has a property 'p' > - A, B, C, and D map to distinct tables > > I am trying to retrieve all A's which have a given value for 'p' in > the D associated with the related B or C (whichever one it is). So: > > select x from A where A.abs.com.p = ? > > A.abs has type S, the abstract superclass; A.abs.com has type D. This > means that the query needs to generate some sort of interesting join > to check for both possible paths to D (via B or C), knowing that > either B or C will have exactly one row satisfying the join > condition(s). In pseudocode: > > select x from A where > if A.abs instanceof B then ((B) A.abs).com.p = ? > else if A.abs instanceof C then ((C) A.abs).com.p = ? > > Should I expect this to work? The SQL query which is being generated > is not only incorrect but invalid: OJB does not rewrite 'p', and in > fact does not even mention D at all. I assume this has to do with > the fact that the repository doesn't record the presence of the > relationship 'com' in the abstract superclass, but only in the > subclasses. Queries starting from B or C and following the 'com' > relationship work fine. Am I out of luck, or is there some way I can > get a working query out of this? > > thanks for any insights, > Steve Clark > Technology Applications Team > Natural Resources Research Center/USGS > [EMAIL PROTECTED] > (970)226-9291 > > PS: Original message below. Name mappings: > > A = PartnerImpl > B = SubSiteImpl > C = TechAssistImpl > D = SiteImpl > S = AccomplishmentImpl > > abs = accomp > com = site > p = habTypeCode > > sc> I'm having a problem with extents in ODMG. OJB is generating > sc> incorrect (and, in fact, invalid) SQL for my OQL query. I'm > sc> using RC5. > > sc> My data model consists of Sites, which have collections of > sc> each of two kinds of Accomplishments (SubSites and > sc> TechAssists). An Accomplishment has a collection of Partners. > sc> In the reverse direction, each Partner is associated with > sc> exactly one Accomplishment (either a SubSite or a TechAssist), > sc> and an Accomplishment knows about its parent Site. My > sc> repository looks like this: > > sc> > > sc> sc> class="gov.doi.habits.dataobjects.SiteImpl" > sc> table="SITE_DETAIL" > sc> proxy="dynamic"> > > sc>sc> name="siteKey" > sc> column="SITE_KEY" &g
RE: Extent problem with ODMG
Hi, I have a hunch - quite possibly misplaced - that this may have something to do the bug I reported in the thhread entitled. "Criteria.setClassPath - the saga continues" Although you are using an ODMG query, when the query is parsed, it does generate a standard QueryByCriteria. QueryByCriteria was getting the wrong class descriptor when paths of > 1 sement were used. This would lead to the attribute name being passed to the query, as opposed to the column name. Jakob fixed this in CVS last night. This May Be A Red Herring. Cheers, Charles. > -Original Message- > From: Steve Clark [mailto:[EMAIL PROTECTED] > Sent: 03 March 2004 19:56 > To: OJB Users List > Subject: Re: Extent problem with ODMG > > > I'm still having this problem, so I'm going to try again. > > Using ODMG, RC5, Oracle 9i. > > Summary: > - Class A has a 1-to-1 relationship 'abs' to an abstract > superclass S > - Class S has concrete subclasses B and C > - Classes B and C share a common relationship 'com' to another > class D; this relationship is defined in the superclass S > - Class D has a property 'p' > - A, B, C, and D map to distinct tables > > I am trying to retrieve all A's which have a given value for 'p' in > the D associated with the related B or C (whichever one it is). So: > > select x from A where A.abs.com.p = ? > > A.abs has type S, the abstract superclass; A.abs.com has type D. This > means that the query needs to generate some sort of interesting join > to check for both possible paths to D (via B or C), knowing that > either B or C will have exactly one row satisfying the join > condition(s). In pseudocode: > > select x from A where > if A.abs instanceof B then ((B) A.abs).com.p = ? > else if A.abs instanceof C then ((C) A.abs).com.p = ? > > Should I expect this to work? The SQL query which is being generated > is not only incorrect but invalid: OJB does not rewrite 'p', and in > fact does not even mention D at all. I assume this has to do with > the fact that the repository doesn't record the presence of the > relationship 'com' in the abstract superclass, but only in the > subclasses. Queries starting from B or C and following the 'com' > relationship work fine. Am I out of luck, or is there some way I can > get a working query out of this? > > thanks for any insights, > Steve Clark > Technology Applications Team > Natural Resources Research Center/USGS > [EMAIL PROTECTED] > (970)226-9291 > > PS: Original message below. Name mappings: > > A = PartnerImpl > B = SubSiteImpl > C = TechAssistImpl > D = SiteImpl > S = AccomplishmentImpl > > abs = accomp > com = site > p = habTypeCode > > sc> I'm having a problem with extents in ODMG. OJB is generating > sc> incorrect (and, in fact, invalid) SQL for my OQL query. I'm > sc> using RC5. > > sc> My data model consists of Sites, which have collections of > sc> each of two kinds of Accomplishments (SubSites and > sc> TechAssists). An Accomplishment has a collection of Partners. > sc> In the reverse direction, each Partner is associated with > sc> exactly one Accomplishment (either a SubSite or a TechAssist), > sc> and an Accomplishment knows about its parent Site. My > sc> repository looks like this: > > sc> > > sc> sc> class="gov.doi.habits.dataobjects.SiteImpl" > sc> table="SITE_DETAIL" proxy="dynamic"> > > sc>sc> name="siteKey" column="SITE_KEY" jdbc-type="INTEGER" > sc> primarykey="true" autoincrement="true"/> > > sc>sc> name="habTypeCode" column="HAB_TYPE_CODE" > sc> jdbc-type="INTEGER" /> > > sc>sc> name="subSites" > sc> > element-class-ref="gov.doi.habits.dataobjects.SubSiteImpl" > sc> > collection-class="org.apache.ojb.broker.util.collections.Manag > eableArrayList"> > sc> > sc> > > sc>sc> name="techAssists" > sc> > element-class-ref="gov.doi.habits.dataobjects.TechAssistImpl" > sc> > collection-class="org.apache.ojb.broker.util.collections.Manag > eableArrayList"> > sc> > sc> > sc> > > sc> > > sc
Re: Extent problem with ODMG
I'm still having this problem, so I'm going to try again. Using ODMG, RC5, Oracle 9i. Summary: - Class A has a 1-to-1 relationship 'abs' to an abstract superclass S - Class S has concrete subclasses B and C - Classes B and C share a common relationship 'com' to another class D; this relationship is defined in the superclass S - Class D has a property 'p' - A, B, C, and D map to distinct tables I am trying to retrieve all A's which have a given value for 'p' in the D associated with the related B or C (whichever one it is). So: select x from A where A.abs.com.p = ? A.abs has type S, the abstract superclass; A.abs.com has type D. This means that the query needs to generate some sort of interesting join to check for both possible paths to D (via B or C), knowing that either B or C will have exactly one row satisfying the join condition(s). In pseudocode: select x from A where if A.abs instanceof B then ((B) A.abs).com.p = ? else if A.abs instanceof C then ((C) A.abs).com.p = ? Should I expect this to work? The SQL query which is being generated is not only incorrect but invalid: OJB does not rewrite 'p', and in fact does not even mention D at all. I assume this has to do with the fact that the repository doesn't record the presence of the relationship 'com' in the abstract superclass, but only in the subclasses. Queries starting from B or C and following the 'com' relationship work fine. Am I out of luck, or is there some way I can get a working query out of this? thanks for any insights, Steve Clark Technology Applications Team Natural Resources Research Center/USGS [EMAIL PROTECTED] (970)226-9291 PS: Original message below. Name mappings: A = PartnerImpl B = SubSiteImpl C = TechAssistImpl D = SiteImpl S = AccomplishmentImpl abs = accomp com = site p = habTypeCode sc> I'm having a problem with extents in ODMG. OJB is generating sc> incorrect (and, in fact, invalid) SQL for my OQL query. I'm sc> using RC5. sc> My data model consists of Sites, which have collections of sc> each of two kinds of Accomplishments (SubSites and sc> TechAssists). An Accomplishment has a collection of Partners. sc> In the reverse direction, each Partner is associated with sc> exactly one Accomplishment (either a SubSite or a TechAssist), sc> and an Accomplishment knows about its parent Site. My sc> repository looks like this: sc> sc> class="gov.doi.habits.dataobjects.SiteImpl" sc> table="SITE_DETAIL" proxy="dynamic"> sc> name="siteKey" column="SITE_KEY" jdbc-type="INTEGER" sc> primarykey="true" autoincrement="true"/> sc> name="habTypeCode" column="HAB_TYPE_CODE" sc> jdbc-type="INTEGER" /> sc> name="subSites" sc> element-class-ref="gov.doi.habits.dataobjects.SubSiteImpl" sc> collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList"> sc> sc> sc> name="techAssists" sc> element-class-ref="gov.doi.habits.dataobjects.TechAssistImpl" sc> collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList"> sc> sc> sc> sc> sc> class="gov.doi.habits.dataobjects.AccomplishmentImpl" > sc> class-ref="gov.doi.habits.dataobjects.SubSiteImpl" /> sc> class-ref="gov.doi.habits.dataobjects.AssistImpl" /> sc> sc> sc> class="gov.doi.habits.dataobjects.SubSiteImpl" sc> table="SUB_SITE_DETAIL" proxy="dynamic"> sc> name="accompKey" column="ACCOMP_KEY" jdbc-type="INTEGER" sc> primarykey="true" autoincrement="true" sc> sequence-name="SEQ_ACCOMP_DETAIL" /> sc> name="siteKey" column="SITE_KEY" jdbc-type="INTEGER" /> sc> name="site" sc> class-ref="gov.doi.habits.dataobjects.SiteImpl"> sc> sc> sc> name="partners" sc> element-class-ref="gov.doi.habits.dataobjects.PartnerImpl" sc> collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList"> sc> sc> sc> sc> sc> class="gov.doi.habits.dataobjects.TechAssistImpl" sc> table="ASSIST_DETAIL" proxy="dynamic"> sc> name="accompKey" column="ACCOMP_KEY" jdbc-type="INTEGER" sc> primarykey="true" autoincrement="true" sc> sequence-name="SEQ_ACCOMP_DETAIL" /> sc> name="siteKey" column="SITE_KEY" jdbc-type="INTEGER" /> sc> name="site" sc> class-ref="gov.doi.habits.dataobjects.SiteImpl"> sc> sc> sc> name="partners" sc> element-class-ref="gov.doi.habits.dataobjects.PartnerImpl" sc> collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList"> sc> sc> sc> sc> sc> class="gov.doi.habits.dataobjects
AW: AW: AW: Extent
hm. in my last download of ojb-1.0rc5 (dec. 2003) there was no docu about the xdoclet support. however I got it from the cvs version and it works now. thanks. Dirk -Ursprüngliche Nachricht- Von: Thomas Dudziak [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 2. März 2004 10:54 An: OJB Users List Betreff: Re: AW: AW: Extent On Tue, 2 Mar 2004, Dirk Manske (Service Respond) wrote: > thanks for the answer Tom. I need more information about the > ojb.modify-inherited tag. You say I could control which attribute will > be picked up. How? Here is the scenario: The BaseClass holds all the > "common attributes". For some objects (extended from BaseClass) all > these common attributes have to be persisted while for some other > objects (also extended from BaseClass) only a few of them have to be > persisted. The problem is, that the generated repository now holds all > the common attributes for each class-descriptor but I do not need them > for each class. could the ojb.modify-inherited tag help me in this > case? An example of how to exclude an attribute for specific classes > would be great. thx, There is one in the docs for the xdoclet-module. Bascially, you state the inherited feature that you want to modify (via the name) and then you have 'ignore="true"' for it. You should be careful with modification (though ignore should be safe) as the xdoclet-module probably allows far more than OJB. Tom - 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: AW: AW: Extent
On Tue, 2 Mar 2004, Dirk Manske (Service Respond) wrote: > thanks for the answer Tom. I need more information about the > ojb.modify-inherited tag. You say I could control which attribute will be > picked up. How? Here is the scenario: The BaseClass holds all the "common > attributes". For some objects (extended from BaseClass) all these common > attributes have to be persisted while for some other objects (also extended > from BaseClass) only a few of them have to be persisted. The problem is, > that the generated repository now holds all the common attributes for each > class-descriptor but I do not need them for each class. could the > ojb.modify-inherited tag help me in this case? An example of how to exclude > an attribute for specific classes would be great. thx, There is one in the docs for the xdoclet-module. Bascially, you state the inherited feature that you want to modify (via the name) and then you have 'ignore="true"' for it. You should be careful with modification (though ignore should be safe) as the xdoclet-module probably allows far more than OJB. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: AW: Extent
thanks for the answer Tom. I need more information about the ojb.modify-inherited tag. You say I could control which attribute will be picked up. How? Here is the scenario: The BaseClass holds all the "common attributes". For some objects (extended from BaseClass) all these common attributes have to be persisted while for some other objects (also extended from BaseClass) only a few of them have to be persisted. The problem is, that the generated repository now holds all the common attributes for each class-descriptor but I do not need them for each class. could the ojb.modify-inherited tag help me in this case? An example of how to exclude an attribute for specific classes would be great. thx, Dirk -Ursprüngliche Nachricht- Von: Thomas Dudziak [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 29. Februar 2004 21:03 An: OJB Users List Betreff: Re: AW: Extent On Sun, 29 Feb 2004, Dirk Manske (Service Respond) wrote: > Hi Peter, > > my first repository-user.xml does not contain the extent concept at > all. I simply did not set up a class-descriptor for BaseClass - just > as you described. > > The extent concept came up to my mind when I thought that XDoclet > would be a great time saver to set up the repository. For each > attribute in the model class you declare an ojb.field, ojb.reference > etc. Since the common attributes are in BaseClass I wondered how to > set them up via XDoclet for each model class. That is why I guess U have to use the extent concept of > ojb. Simply put the required tags (ojb.field, ojb.reference etc.) in the BaseClass. There is no need to tag the BaseClass with ojb.class, the XDoclet module will pick up any inherited persistent (tagged) features regardless of whether their class is persistent (ojb.class) or not, and add them to the current class descriptor. You can also control which features are picked up via the ojb.modify-inherited tag, which also allows you to modify them for the current class. Tom - 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: AW: Extent
On Sun, 29 Feb 2004, Dirk Manske (Service Respond) wrote: > Hi Peter, > > my first repository-user.xml does not contain the extent concept at all. I > simply did not set up a class-descriptor for BaseClass - just as you > described. > > The extent concept came up to my mind when I thought that XDoclet would be a > great time saver to set up the repository. For each attribute in the model > class you declare an ojb.field, ojb.reference etc. Since the common > attributes are in BaseClass I wondered how to set them up via XDoclet for > each model class. That is why I guess U have to use the extent concept of > ojb. Simply put the required tags (ojb.field, ojb.reference etc.) in the BaseClass. There is no need to tag the BaseClass with ojb.class, the XDoclet module will pick up any inherited persistent (tagged) features regardless of whether their class is persistent (ojb.class) or not, and add them to the current class descriptor. You can also control which features are picked up via the ojb.modify-inherited tag, which also allows you to modify them for the current class. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Extent
Hi Dirk, sorry, no idea how to use this with XDoclet. I pass on the question to the community. We use AXgen to generate everything based on an UML metamodel... Peter > Hi Peter, > my first repository-user.xml does not contain the extent concept at all. I > simply did not set up a class-descriptor for BaseClass - just as you > described. > The extent concept came up to my mind when I thought that XDoclet would be > a > great time saver to set up the repository. For each attribute in the model > class you declare an ojb.field, ojb.reference etc. Since the common > attributes are in BaseClass I wondered how to set them up via XDoclet for > each model class. That is why I guess U have to use the extent concept of > ojb. > Any idea? > Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Extent
Hi Peter, my first repository-user.xml does not contain the extent concept at all. I simply did not set up a class-descriptor for BaseClass - just as you described. The extent concept came up to my mind when I thought that XDoclet would be a great time saver to set up the repository. For each attribute in the model class you declare an ojb.field, ojb.reference etc. Since the common attributes are in BaseClass I wondered how to set them up via XDoclet for each model class. That is why I guess U have to use the extent concept of ojb. Any idea? Dirk -Ursprüngliche Nachricht- Von: Peter Wieland [mailto:[EMAIL PROTECTED] Gesendet: Sonntag, 29. Februar 2004 16:47 An: [EMAIL PROTECTED] Betreff: Re: Extent Hi Dirk, I'm not sure whether I understood your problem. Maybe I can help anyway... First, I'm not sure whether you really need to declare the extents for all your classes. Wouldn't it be sufficient to simply have all model classes having the same superclass BaseClass. If this is the case, simply model write a class-descriptor for each model class without any extent declarations. The BaseClass doesn't even need an entry in the repository file. Of course, if you need to do queries using the BaseClass, this approach won't work. You would then need to declare the BaseClass in the repository with all it's extents. This would probably look like ... In the latter case, I think you would have to redeclare the id and version fields in each extent class together with the specific attributes for each extent class: I'm not quite sure, whether it is really necessary to redeclare the common fields in each extent class, but I'm sure that it works this way as we are using this approach. The column names for the extent classes do not need to be the same for the same fields in different extent classes. Using the extent-approach, you will have one separate table for each model class, containing all the needed columns, included the "inherited" ones. Hope that helps, Peter > Hi, > I am using PB-API and DB2 7 for a few weeks now and have a question > regarding the ojb extent concept. > I have a BaseClass which holds common attributes (timestamp, > versionnr) for model objects. Each model class has to extent > BaseClass. Database tables hold the common attributes and specific > attributes for the appropriate model class. > In the repository-user.xml I declared the common attributes separately > for each model class-descriptor. My question is: Did I miss the > ojb-extent concept totally? Could I just declare a model class as an > extent-class of BaseClass and delete the common attributes from each > (model)class-descriptor because of the extent, ojb would handle these > attributes automatically for each extended class? > thx, > Dirk > - > 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: Extent
Hi Dirk, I'm not sure whether I understood your problem. Maybe I can help anyway... First, I'm not sure whether you really need to declare the extents for all your classes. Wouldn't it be sufficient to simply have all model classes having the same superclass BaseClass. If this is the case, simply model write a class-descriptor for each model class without any extent declarations. The BaseClass doesn't even need an entry in the repository file. Of course, if you need to do queries using the BaseClass, this approach won't work. You would then need to declare the BaseClass in the repository with all it's extents. This would probably look like ... In the latter case, I think you would have to redeclare the id and version fields in each extent class together with the specific attributes for each extent class: I'm not quite sure, whether it is really necessary to redeclare the common fields in each extent class, but I'm sure that it works this way as we are using this approach. The column names for the extent classes do not need to be the same for the same fields in different extent classes. Using the extent-approach, you will have one separate table for each model class, containing all the needed columns, included the "inherited" ones. Hope that helps, Peter > Hi, > I am using PB-API and DB2 7 for a few weeks now and have a question > regarding the ojb extent concept. > I have a BaseClass which holds common attributes (timestamp, versionnr) > for > model objects. Each model class has to extent BaseClass. Database tables > hold the common attributes and specific attributes for the appropriate > model > class. > In the repository-user.xml I declared the common attributes separately for > each model class-descriptor. My question is: Did I miss the ojb-extent > concept totally? Could I just declare a model class as an extent-class of > BaseClass and delete the common attributes from each > (model)class-descriptor > because of the extent, ojb would handle these attributes automatically for > each extended class? > thx, > Dirk > - > 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]
Extent
Hi, I am using PB-API and DB2 7 for a few weeks now and have a question regarding the ojb extent concept. I have a BaseClass which holds common attributes (timestamp, versionnr) for model objects. Each model class has to extent BaseClass. Database tables hold the common attributes and specific attributes for the appropriate model class. In the repository-user.xml I declared the common attributes separately for each model class-descriptor. My question is: Did I miss the ojb-extent concept totally? Could I just declare a model class as an extent-class of BaseClass and delete the common attributes from each (model)class-descriptor because of the extent, ojb would handle these attributes automatically for each extended class? thx, Dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent problem with ODMG
hi steve, imo OQL is not the problem here. have you tried to query for AccomplishmentImp, just to see if 'site' can be resolved ? may be you should use the latest from repository. jakob Steve Clark wrote: I'm having a problem with extents in ODMG. OJB is generating incorrect (and, in fact, invalid) SQL for my OQL query. I'm using RC5. My data model consists of Sites, which have collections of each of two kinds of Accomplishments (SubSites and TechAssists). An Accomplishment has a collection of Partners. In the reverse direction, each Partner is associated with exactly one Accomplishment (either a SubSite or a TechAssist), and an Accomplishment knows about its parent Site. My repository looks like this: name="subSites" element-class-ref="gov.doi.habits.dataobjects.SubSiteImpl" collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList"> name="techAssists" element-class-ref="gov.doi.habits.dataobjects.TechAssistImpl" collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList"> name="partners" element-class-ref="gov.doi.habits.dataobjects.PartnerImpl" collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList"> name="partners" element-class-ref="gov.doi.habits.dataobjects.PartnerImpl" collection-class="org.apache.ojb.broker.util.collections.ManageableArrayList"> My query looks like this: 15:41:13,896 DEBUG [] accesslayer.JdbcAccessImpl (JdbcAccessImpl.java:282) - executeQuery : Query from class gov.doi.habits.dataobjects.PartnerImpl where [accomp.site.habTypeCode IN [1]] Note that partner.accomp is an Accomplishment (the abstract superclass); both extents (SubSite and TechAssist) have a site relationship. The generated SQL looks like this: 15:41:13,901 DEBUG [] sql.SqlGeneratorDefaultImpl (SqlGeneratorDefaultImpl.java:200) - SQL:SELECT DISTINCT A0.ACCOMP_KEY,A0.PARTNER_KEY FROM PARTNER_DETAIL A0,SUB_SITE_DETAIL A1,ASSIST_DETAIL A1E1 WHERE A0.ACCOMP_KEY=A1.ACCOMP_KEY(+) AND A0.ACCOMP_KEY=A1E1.ACCOMP_KEY(+) AND ((habTypeCode IN ( ? ) OR habTypeCode IN ( ? ))) Note that SITE_DETAIL is not even included in the query, and habTypeCode as a result is not rewritten to the appropriate column name. I think the correct query would be more like this: SELECT DISTINCT A0.ACCOMP_KEY,A0.PARTNER_KEY FROM PARTNER_DETAIL A0,SUB_SITE_DETAIL A1,ASSIST_DETAIL A1E1,SITE_DETAIL A2 WHERE ((A0.ACCOMP_KEY=A1.ACCOMP_KEY(+) AND A1.SITE_KEY=A2.SITE_KEY) OR (A0.ACCOMP_KEY=A1E1.ACCOMP_KEY(+) AND A1E1.SITE_KEY=A2.SITE_KEY)) AND (A2.HAB_TYPE_CODE IN ( ? )) ... though I'm not sure that's exactly right even. Is there a way to get working SQL out of this OQL? thanks, - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Extent problem with ODMG
I'm having a problem with extents in ODMG. OJB is generating incorrect (and, in fact, invalid) SQL for my OQL query. I'm using RC5. My data model consists of Sites, which have collections of each of two kinds of Accomplishments (SubSites and TechAssists). An Accomplishment has a collection of Partners. In the reverse direction, each Partner is associated with exactly one Accomplishment (either a SubSite or a TechAssist), and an Accomplishment knows about its parent Site. My repository looks like this: My query looks like this: 15:41:13,896 DEBUG [] accesslayer.JdbcAccessImpl (JdbcAccessImpl.java:282) - executeQuery : Query from class gov.doi.habits.dataobjects.PartnerImpl where [accomp.site.habTypeCode IN [1]] Note that partner.accomp is an Accomplishment (the abstract superclass); both extents (SubSite and TechAssist) have a site relationship. The generated SQL looks like this: 15:41:13,901 DEBUG [] sql.SqlGeneratorDefaultImpl (SqlGeneratorDefaultImpl.java:200) - SQL:SELECT DISTINCT A0.ACCOMP_KEY,A0.PARTNER_KEY FROM PARTNER_DETAIL A0,SUB_SITE_DETAIL A1,ASSIST_DETAIL A1E1 WHERE A0.ACCOMP_KEY=A1.ACCOMP_KEY(+) AND A0.ACCOMP_KEY=A1E1.ACCOMP_KEY(+) AND ((habTypeCode IN ( ? ) OR habTypeCode IN ( ? ))) Note that SITE_DETAIL is not even included in the query, and habTypeCode as a result is not rewritten to the appropriate column name. I think the correct query would be more like this: SELECT DISTINCT A0.ACCOMP_KEY,A0.PARTNER_KEY FROM PARTNER_DETAIL A0,SUB_SITE_DETAIL A1,ASSIST_DETAIL A1E1,SITE_DETAIL A2 WHERE ((A0.ACCOMP_KEY=A1.ACCOMP_KEY(+) AND A1.SITE_KEY=A2.SITE_KEY) OR (A0.ACCOMP_KEY=A1E1.ACCOMP_KEY(+) AND A1E1.SITE_KEY=A2.SITE_KEY)) AND (A2.HAB_TYPE_CODE IN ( ? )) ... though I'm not sure that's exactly right even. Is there a way to get working SQL out of this OQL? thanks, -- Steve Clark Technology Applications Team Natural Resources Research Center/USGS [EMAIL PROTECTED] (970)226-9291 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JDO Query/Extent Problem
I'm really interested in the answer to this, as I am embarking on using the JDO API right now. This could be really inconvenient. -Gus Nick Ohanian wrote: Hi- There was a thread on this list regarding the fact that when using JDO, Extent or Query results act transient, not persistent. That is, if you look up an object with a Query and edit it, those changes are not persisted back to the database on commit. The only way to get a "really" persistent object is to look it up by an Identity. Note that this is the kind of lookup used by Tutorial 4. Indeed if you look at the source for UCEditProduct (the actual file in src/jdori/org/apache/ojb/tutorial5/UCEditProduct.java, not the source on the Tutorial 4 web page), you can see that the use of a Query object appears to be commented out in place of the Identity object. The thread that I'm referring to can be found here (it explains things in some more detail): http://www.mail-archive.com/[EMAIL PROTECTED]/msg03832.html This makes the JDO API... less than ideal. ;) Has this problem been addressed already? Is there a fix available? Thanks so much, Nick - 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]
JDO Query/Extent Problem
Hi- There was a thread on this list regarding the fact that when using JDO, Extent or Query results act transient, not persistent. That is, if you look up an object with a Query and edit it, those changes are not persisted back to the database on commit. The only way to get a "really" persistent object is to look it up by an Identity. Note that this is the kind of lookup used by Tutorial 4. Indeed if you look at the source for UCEditProduct (the actual file in src/jdori/org/apache/ojb/tutorial5/UCEditProduct.java, not the source on the Tutorial 4 web page), you can see that the use of a Query object appears to be commented out in place of the Identity object. The thread that I'm referring to can be found here (it explains things in some more detail): http://www.mail-archive.com/[EMAIL PROTECTED]/msg03832.html This makes the JDO API... less than ideal. ;) Has this problem been addressed already? Is there a fix available? Thanks so much, Nick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wrong class materialized when selecting from an extent mapped to a multi-table join
So, changing the class descriptor for B to read something like: should clear up any ambiguity and give me behavior more in-line with my original message, yes? Thanks for your help! > -Original Message- > From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 19, 2003 3:26 AM > To: OJB Users List > Subject: Re: Wrong class materialized when selecting from an extent > mapped to a multi-table join > > > hi justis, > > ojb needs the pk to be unique within a hierarchy. > Identity#equals just > checks for the toplevel class not the real class, that's why. > changing > this behaviour is delicate. > > afaik the tutorial simply uses the super-reference (with the same pk) > but it does _not_ use extent-definitions. so the classes do > not belong > to the same hierarchy and thus an identical pk does not hurt. > > jakob > > Justis Peters wrote: > > Hi Jakob, > > > > The answers you provide Burt imply that it is possible to > do exactly what I am trying to do. What is it that I am > doing wrong? My test cases seem to follow exactly what Burt is doing. > > > > Also, I do not understand your comment about the primary > key needing to be unique. The tutorial specifically > recommends using the same primary key for both, in order to > link the rows together. In the case we are discussing below, > the data in A_TABLE is not an object referenced by B_TABLE -- > it is actually the data that comprises the remainder of > B_TABLE. It is just stored in A_TABLE instead, to avoid > redundancy and to allow for selecting from the entire extent > when using tools other than OJB. > > > > Am I misunderstanding something? I realize that the > current implementation of the super-reference does not do > what I am requesting. It seems to me, though, that it should > eventually do this. > > > > Thanks in advance for your reply! > > > > Sincerely yours, > > Justis Peters > > Oculan Corp. > > [EMAIL PROTECTED] > > > > Jakob Braeuchi [EMAIL PROTECTED] wrote: > > > >>hi burt, > >> > >>1.) this is partly correct: > >>three queries will be executed to load the extents. > problems could arise > >>when materializing the objects. ojb assumes that a primary key is > >>_unique_ within a class hierarchy. if this is not true the > wrong object > >>will be returned. this could be solved here by _not_ using > the pk in > >>super-reference. > >> > >>2.) same problem as in 1.) > >> > >>3.) that's true atm. > >> > >>4.) also true if the auto-settings of the reference > descriptor are not > >>set to false. > >> > >>jakob > >> > >>BURT, RANDALL (CONTRACTOR) wrote: > >> > >> > >>>Jumping in late, but its germane to what I'm working on. > So, if I read > >>>what everyone is saying correctly, the following: > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> >>> primarykey="true" > autoincrement="true" /> > >>>>>> jdbc-type="INTEGER" /> > >>> > >>> > >>> > >>>>>> primarykey="true" > autoincrement="true" /> > >>>>>> jdbc-type="INTEGER" /> > >>> > >>> > >>> > >>> > >>> > >>> > >>>>>> primarykey="true" > autoincrement="true" /> > >>>>>> jdbc-type="INTEGER" /> > >>> > >>> > >>>does not do what I would expect? : > >>> > >>>1. Queries for collections of InterfaceA would give me all > the A's, B's, > >>>and C's. > >>>2. Queries for collections of A's would give me A's and > B's, but the A's > >>>would be only those rows in A_TABLE that did not have > matching keys in > >>>B_TABLE. > >>>3. If I queried for an A, but there is a B that matches, > I'd get a B and > >>>not just an A. > >>>4. Anytime B's are materialized, they would have thei
Re: Wrong class materialized when selecting from an extent mapped to a multi-table join
hi justis, ojb needs the pk to be unique within a hierarchy. Identity#equals just checks for the toplevel class not the real class, that's why. changing this behaviour is delicate. afaik the tutorial simply uses the super-reference (with the same pk) but it does _not_ use extent-definitions. so the classes do not belong to the same hierarchy and thus an identical pk does not hurt. jakob Justis Peters wrote: Hi Jakob, The answers you provide Burt imply that it is possible to do exactly what I am trying to do. What is it that I am doing wrong? My test cases seem to follow exactly what Burt is doing. Also, I do not understand your comment about the primary key needing to be unique. The tutorial specifically recommends using the same primary key for both, in order to link the rows together. In the case we are discussing below, the data in A_TABLE is not an object referenced by B_TABLE -- it is actually the data that comprises the remainder of B_TABLE. It is just stored in A_TABLE instead, to avoid redundancy and to allow for selecting from the entire extent when using tools other than OJB. Am I misunderstanding something? I realize that the current implementation of the super-reference does not do what I am requesting. It seems to me, though, that it should eventually do this. Thanks in advance for your reply! Sincerely yours, Justis Peters Oculan Corp. [EMAIL PROTECTED] Jakob Braeuchi [EMAIL PROTECTED] wrote: hi burt, 1.) this is partly correct: three queries will be executed to load the extents. problems could arise when materializing the objects. ojb assumes that a primary key is _unique_ within a class hierarchy. if this is not true the wrong object will be returned. this could be solved here by _not_ using the pk in super-reference. 2.) same problem as in 1.) 3.) that's true atm. 4.) also true if the auto-settings of the reference descriptor are not set to false. jakob BURT, RANDALL (CONTRACTOR) wrote: Jumping in late, but its germane to what I'm working on. So, if I read what everyone is saying correctly, the following: does not do what I would expect? : 1. Queries for collections of InterfaceA would give me all the A's, B's, and C's. 2. Queries for collections of A's would give me A's and B's, but the A's would be only those rows in A_TABLE that did not have matching keys in B_TABLE. 3. If I queried for an A, but there is a B that matches, I'd get a B and not just an A. 4. Anytime B's are materialized, they would have their inherited properties from the super class A populated. Sorry if this is a re-hash, but I'm getting a little confused ATM. Thanks for any clarifications. -Original Message- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 12:09 PM To: OJB Users List; Thomas Mahler; Armin Waibel Subject: Re: Wrong class materialized when selecting from an extent mapped to a multi-table join hi justis, wallace, this problem is caused by Identity#equals noch checking objectsRealClass . consider the following situation: a select for InterfaceA fires 2 selects SELECT A0.VALUE_,A0.ID FROM A_TABLE A0 retrieving Table_A objects with ids 1 and 2 SELECT A0.VALUE_,A0.ID FROM B_TABLE A0 INNER JOIN A_TABLE A1 ON A0.ID=A1.ID retrieving Table_B object with id 1 when building the objects from the resultset in RsIterator#getObjectFromResultSet an identity is built from the row and looked up in the cache. the object (id = 1) from table_B is considered to be in the cache because the topLevelClass (InterfaceA) and the pk (1) matches ! this problem could be solved by also checking the objectsRealClass in Identity#equals. i remember there was quite a big discussion about Identity, so i'm not sure if this is a correct soluion ?? another solution could be to use a dedicated column to refer to the super-class in the reference-descriptor. this would avoid the pk-clash in the cache. another way is to completly avoid using extents and super-references ;) jakob Justis Peters wrote: Hi All! Just a couple weeks ago I started using OJB, and I am extremely impressed. My gratitude goes to all who put in the work to make it possible. Upon converting some of the more complicated parts of my object model, I encountered a strange issue. Here is the bug I attempted to submit to scarab. Apparently, scarab is having problems. At first, it assigned an ID to my issue that was already assigned to another issue, so I can't retrieve it. Now, it won't let me enter new issues and keeps directing me to the query page isntead. Anyhow, here is the summary of the bug. Any help would be appreciated: ====== When selecting an entire extent from a parent class, the behavior
Re: Wrong class materialized when selecting from an extent mapped to a multi-table join
Hi Jakob, The answers you provide Burt imply that it is possible to do exactly what I am trying to do. What is it that I am doing wrong? My test cases seem to follow exactly what Burt is doing. Also, I do not understand your comment about the primary key needing to be unique. The tutorial specifically recommends using the same primary key for both, in order to link the rows together. In the case we are discussing below, the data in A_TABLE is not an object referenced by B_TABLE -- it is actually the data that comprises the remainder of B_TABLE. It is just stored in A_TABLE instead, to avoid redundancy and to allow for selecting from the entire extent when using tools other than OJB. Am I misunderstanding something? I realize that the current implementation of the super-reference does not do what I am requesting. It seems to me, though, that it should eventually do this. Thanks in advance for your reply! Sincerely yours, Justis Peters Oculan Corp. [EMAIL PROTECTED] Jakob Braeuchi [EMAIL PROTECTED] wrote: > hi burt, > > 1.) this is partly correct: > three queries will be executed to load the extents. problems could arise > when materializing the objects. ojb assumes that a primary key is > _unique_ within a class hierarchy. if this is not true the wrong object > will be returned. this could be solved here by _not_ using the pk in > super-reference. > > 2.) same problem as in 1.) > > 3.) that's true atm. > > 4.) also true if the auto-settings of the reference descriptor are not > set to false. > > jakob > > BURT, RANDALL (CONTRACTOR) wrote: > > >Jumping in late, but its germane to what I'm working on. So, if I read > >what everyone is saying correctly, the following: > > > > > > > > > > > > > > > > > > > > > primarykey="true" autoincrement="true" /> > > > jdbc-type="INTEGER" /> > > > > > > > > > primarykey="true" autoincrement="true" /> > > > jdbc-type="INTEGER" /> > > > > > > > > > > > > > > > primarykey="true" autoincrement="true" /> > > > jdbc-type="INTEGER" /> > > > > > >does not do what I would expect? : > > > >1. Queries for collections of InterfaceA would give me all the A's, B's, > >and C's. > >2. Queries for collections of A's would give me A's and B's, but the A's > >would be only those rows in A_TABLE that did not have matching keys in > >B_TABLE. > >3. If I queried for an A, but there is a B that matches, I'd get a B and > >not just an A. > >4. Anytime B's are materialized, they would have their inherited > >properties from the super class A populated. > > > >Sorry if this is a re-hash, but I'm getting a little confused ATM. Thanks > >for any clarifications. > > > > > >>-Original Message- > >>From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] > >>Sent: Friday, October 17, 2003 12:09 PM > >>To: OJB Users List; Thomas Mahler; Armin Waibel > >>Subject: Re: Wrong class materialized when selecting from an extent > >>mapped to a multi-table join > >> > >> > >>hi justis, wallace, > >> > >>this problem is caused by Identity#equals noch checking > >>objectsRealClass > >>. consider the following situation: a select for InterfaceA > >>fires 2 selects > >>SELECT A0.VALUE_,A0.ID FROM A_TABLE A0 > >>retrieving Table_A objects with ids 1 and 2 > >>SELECT A0.VALUE_,A0.ID FROM B_TABLE A0 INNER JOIN A_TABLE A1 > >>ON A0.ID=A1.ID > >>retrieving Table_B object with id 1 > >> > >>when building the objects from the resultset in > >>RsIterator#getObjectFromResultSet an identity is built from > >>the row and > >>looked up in the cache. the object (id = 1) from table_B is > >>considered > >>to be in the cache because the topLevelClass (InterfaceA) and > >>the pk (1) > >>matches ! > >> > >>this problem could be solved by also checking the objectsRealClass in > >>Identity#equals. i remember there was quite a big discussion about > >>Identity, so i'm not sure if this is a correct soluion ?? > >> > >>another solu
Re: Wrong class materialized when selecting from an extent mapped to a multi-table join
hi burt, 1.) this is partly correct: three queries will be executed to load the extents. problems could arise when materializing the objects. ojb assumes that a primary key is _unique_ within a class hierarchy. if this is not true the wrong object will be returned. this could be solved here by _not_ using the pk in super-reference. 2.) same problem as in 1.) 3.) that's true atm. 4.) also true if the auto-settings of the reference descriptor are not set to false. jakob BURT, RANDALL (CONTRACTOR) wrote: Jumping in late, but its germane to what I'm working on. So, if I read what everyone is saying correctly, the following: does not do what I would expect? : 1. Queries for collections of InterfaceA would give me all the A's, B's, and C's. 2. Queries for collections of A's would give me A's and B's, but the A's would be only those rows in A_TABLE that did not have matching keys in B_TABLE. 3. If I queried for an A, but there is a B that matches, I'd get a B and not just an A. 4. Anytime B's are materialized, they would have their inherited properties from the super class A populated. Sorry if this is a re-hash, but I'm getting a little confused ATM. Thanks for any clarifications. -Original Message- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 12:09 PM To: OJB Users List; Thomas Mahler; Armin Waibel Subject: Re: Wrong class materialized when selecting from an extent mapped to a multi-table join hi justis, wallace, this problem is caused by Identity#equals noch checking objectsRealClass . consider the following situation: a select for InterfaceA fires 2 selects SELECT A0.VALUE_,A0.ID FROM A_TABLE A0 retrieving Table_A objects with ids 1 and 2 SELECT A0.VALUE_,A0.ID FROM B_TABLE A0 INNER JOIN A_TABLE A1 ON A0.ID=A1.ID retrieving Table_B object with id 1 when building the objects from the resultset in RsIterator#getObjectFromResultSet an identity is built from the row and looked up in the cache. the object (id = 1) from table_B is considered to be in the cache because the topLevelClass (InterfaceA) and the pk (1) matches ! this problem could be solved by also checking the objectsRealClass in Identity#equals. i remember there was quite a big discussion about Identity, so i'm not sure if this is a correct soluion ?? another solution could be to use a dedicated column to refer to the super-class in the reference-descriptor. this would avoid the pk-clash in the cache. another way is to completly avoid using extents and super-references ;) jakob Justis Peters wrote: Hi All! Just a couple weeks ago I started using OJB, and I am extremely impressed. My gratitude goes to all who put in the work to make it possible. Upon converting some of the more complicated parts of my object model, I encountered a strange issue. Here is the bug I attempted to submit to scarab. Apparently, scarab is having problems. At first, it assigned an ID to my issue that was already assigned to another issue, so I can't retrieve it. Now, it won't let me enter new issues and keeps directing me to the query page isntead. Anyhow, here is the summary of the bug. Any help would be appreciated: ====== When selecting an entire extent from a parent class, the behavior varies depending on whether you are using multi-table joins or distinct tables for each class. Everything seems to work correctly if you use distinct tables for each class. If you are using multi-table joins, however, your objects are not always materialized as the class you would expect. Here is the scenario for the test case I made: Object model - public interface InterfaceA - public class A implements InterfaceA - public class B extends A implements InterfaceA Test case 1 --- - start with a new JVM - select all from extent InterfaceA.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent B.class, loop through and display the class for each Test case 2 --- - restart with a new JVM - select all from extent B.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent InterfaceA.class, loop through and display the class for each Results --- - If using distinct tables for each class (see schema1.sql and repository_user1.xml), both test cases materialize all objects as the correct subclass and returns the expected instances with the appropriate queries. - If using multi-table joins (see schema2.sql and repository_user2.xml), test case 1 displays everything as being class "A&quo
Re: Wrong class materialized when selecting from an extent mapped to a multi-table join
Hi Jakob,
Thanks for your reply! Perhaps I have some ideas on how we could do this. Here are
two:
Idea 1
--
Join all the columns from all tables in the hierarchy together, and then look to see
which join columns are not null, in order to determine the true subclass
I demonstrate this using three classes, just to make it clear that it could scale
(even if sloppily):
- public class A implements InterfaceA
- public class B extends A implements InterfaceA
- public class C extends A implements InterfaceA
A select for InterfaceA would then do something like this:
SELECT a.id, a.value_, b.id, b.value_, c.id, c.value_
FROM (a_table AS a LEFT OUTER JOIN b_table AS b ON a.id=b.id) LEFT OUTER JOIN c_table
AS c ON a.id=c.id
Materializing would look like this:
//This interface is sketchy, but you'll get the idea (I hope)
HierarchyTree tree = HierarchyTree.getTree(superclassWeQueried)
//Loop over the ResultSet
while (rs.next()) {
Class classToMaterialize = superclassWeQueried;
Class[] classesToCheck = null;
while ((classesToCheck = tree.getBranchBelow(classToMaterialize)) != null) {
for (int i=0; i < classesToCheck.length; i++) {
String currentClassPkeyColumn = getPrimaryKeyColumnName(classesToCheck[i]);
rs.getInt(currentClassPkeyColumn);
if (rs.wasNull()) {
continue;
} else {
//The primary key was not null. Therefore, there is data at or below this
branch
classToMaterialize = classesToCheck[i];
break;
}
}
}
Object newMember = this.materialize(rs, classToMaterialize);
someListOfObjectsToReturn.add(newMember);
}
Idea 2
--
Require that we include a column in each class-descriptor that specifies the class as
which this row should be instantiated. This is just like the model where you have
multiple classes mapped to a single table, except that the materilization processes
would have to know to go digging deeper for the further information.
The drawback with this approach could possibly be that multiple queries would be
required to get the further information. This could be minimized by making a list of
identities that need further queries. Or maybe it could be solved by using proxies.
If you queried for InterfaceA.class, then you would get back objects that are
assignment compatible with the true subclass, but have materialized only the elements
defined in InterfaceA. If you cast it to its subclass and access the deeper parts of
the interface, it would trigger the proxy to perform materialization.
-
Thoughts on any of this? Also, am I off base by thinking this feature should be
supported?
Sincerely yours,
Justis Peters
Oculan Corp.
[EMAIL PROTECTED]
Jakob Braeuchi [EMAIL PROTECTED] wrote:
> hi justis, wallace,
>
> this problem is caused by Identity#equals noch checking objectsRealClass
> . consider the following situation: a select for InterfaceA fires 2 selects
> SELECT A0.VALUE_,A0.ID FROM A_TABLE A0
> retrieving Table_A objects with ids 1 and 2
> SELECT A0.VALUE_,A0.ID FROM B_TABLE A0 INNER JOIN A_TABLE A1 ON A0.ID=A1.ID
> retrieving Table_B object with id 1
>
> when building the objects from the resultset in
> RsIterator#getObjectFromResultSet an identity is built from the row and
> looked up in the cache. the object (id = 1) from table_B is considered
> to be in the cache because the topLevelClass (InterfaceA) and the pk (1)
> matches !
>
> this problem could be solved by also checking the objectsRealClass in
> Identity#equals. i remember there was quite a big discussion about
> Identity, so i'm not sure if this is a correct soluion ??
>
> another solution could be to use a dedicated column to refer to the
> super-class in the reference-descriptor. this would avoid the pk-clash
> in the cache.
>
> another way is to completly avoid using extents and super-references ;)
>
>
>
>
>
>
>
>
>primarykey="true" autoincrement="true" />
>jdbc-type="INTEGER" />
>
>
>
>primarykey="true" autoincrement="true" />
>jdbc-type="INTEGER" />
>
>
>
>
>
> jakob
>
> Justis Peters wrote:
>
> >Hi All!
> >
> >Just a couple weeks ago I started using OJB, and I am extremely impressed.
> >My gratitude goes to all who put in the work to make it possible.
> >
> >Upon converting some of the more complicated parts of my object model, I
> >encountered a strange issue. Here is the bug I attempted to submit to
> >scarab. Apparently, scarab is having problems. At first, it assigned an
> >ID to my issue that was already assigned to another issue, so I can't
> >retrieve it. Now, it won't let me e
RE: Wrong class materialized when selecting from an extent mapped to a multi-table join
Jumping in late, but its germane to what I'm working on. So, if I read what everyone is saying correctly, the following: does not do what I would expect? : 1. Queries for collections of InterfaceA would give me all the A's, B's, and C's. 2. Queries for collections of A's would give me A's and B's, but the A's would be only those rows in A_TABLE that did not have matching keys in B_TABLE. 3. If I queried for an A, but there is a B that matches, I'd get a B and not just an A. 4. Anytime B's are materialized, they would have their inherited properties from the super class A populated. Sorry if this is a re-hash, but I'm getting a little confused ATM. Thanks for any clarifications. > -Original Message- > From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] > Sent: Friday, October 17, 2003 12:09 PM > To: OJB Users List; Thomas Mahler; Armin Waibel > Subject: Re: Wrong class materialized when selecting from an extent > mapped to a multi-table join > > > hi justis, wallace, > > this problem is caused by Identity#equals noch checking > objectsRealClass > . consider the following situation: a select for InterfaceA > fires 2 selects > SELECT A0.VALUE_,A0.ID FROM A_TABLE A0 > retrieving Table_A objects with ids 1 and 2 > SELECT A0.VALUE_,A0.ID FROM B_TABLE A0 INNER JOIN A_TABLE A1 > ON A0.ID=A1.ID > retrieving Table_B object with id 1 > > when building the objects from the resultset in > RsIterator#getObjectFromResultSet an identity is built from > the row and > looked up in the cache. the object (id = 1) from table_B is > considered > to be in the cache because the topLevelClass (InterfaceA) and > the pk (1) > matches ! > > this problem could be solved by also checking the objectsRealClass in > Identity#equals. i remember there was quite a big discussion about > Identity, so i'm not sure if this is a correct soluion ?? > > another solution could be to use a dedicated column to refer to the > super-class in the reference-descriptor. this would avoid the > pk-clash > in the cache. > > another way is to completly avoid using extents and > super-references ;) > > > > > > > > >primarykey="true" autoincrement="true" /> >jdbc-type="INTEGER" /> > > > >primarykey="true" autoincrement="true" /> >jdbc-type="INTEGER" /> > > > > > > jakob > > Justis Peters wrote: > > > Hi All! > > > > Just a couple weeks ago I started using OJB, and I am > extremely impressed. My gratitude goes to all who put in the > work to make it possible. > > > > Upon converting some of the more complicated parts of my > object model, I encountered a strange issue. Here is the bug > I attempted to submit to scarab. Apparently, scarab is > having problems. At first, it assigned an ID to my issue > that was already assigned to another issue, so I can't > retrieve it. Now, it won't let me enter new issues and keeps > directing me to the query page isntead. > > > > Anyhow, here is the summary of the bug. Any help would be > appreciated: > > > > > == > > > When selecting an entire extent from a parent class, the > behavior varies depending on whether you are using > multi-table joins or distinct tables for each class. > Everything seems to work correctly if you use distinct tables > for each class. If you are using multi-table joins, however, > your objects are not always materialized as the class you > would expect. Here is the scenario for the test case I made: > > > > Object model > > > > - public interface InterfaceA > > - public class A implements InterfaceA > > - public class B extends A implements InterfaceA > > > > Test case 1 > > --- > > - start with a new JVM > > - select all from extent InterfaceA.class, loop through and > display the class for each > > - select all from extent A.class, loop through and display > the class for each > > - select all from extent B.class, loop through and display > the class for each > > > > Test case 2 > > --- > > - restart with a new JVM > > - select all from extent B.class, loop through and display > the class for each > > - select all from extent A.class, loop
Re: Wrong class materialized when selecting from an extent mapped to a multi-table join
hi justis, wallace, this problem is caused by Identity#equals noch checking objectsRealClass . consider the following situation: a select for InterfaceA fires 2 selects SELECT A0.VALUE_,A0.ID FROM A_TABLE A0 retrieving Table_A objects with ids 1 and 2 SELECT A0.VALUE_,A0.ID FROM B_TABLE A0 INNER JOIN A_TABLE A1 ON A0.ID=A1.ID retrieving Table_B object with id 1 when building the objects from the resultset in RsIterator#getObjectFromResultSet an identity is built from the row and looked up in the cache. the object (id = 1) from table_B is considered to be in the cache because the topLevelClass (InterfaceA) and the pk (1) matches ! this problem could be solved by also checking the objectsRealClass in Identity#equals. i remember there was quite a big discussion about Identity, so i'm not sure if this is a correct soluion ?? another solution could be to use a dedicated column to refer to the super-class in the reference-descriptor. this would avoid the pk-clash in the cache. another way is to completly avoid using extents and super-references ;) jakob Justis Peters wrote: Hi All! Just a couple weeks ago I started using OJB, and I am extremely impressed. My gratitude goes to all who put in the work to make it possible. Upon converting some of the more complicated parts of my object model, I encountered a strange issue. Here is the bug I attempted to submit to scarab. Apparently, scarab is having problems. At first, it assigned an ID to my issue that was already assigned to another issue, so I can't retrieve it. Now, it won't let me enter new issues and keeps directing me to the query page isntead. Anyhow, here is the summary of the bug. Any help would be appreciated: == When selecting an entire extent from a parent class, the behavior varies depending on whether you are using multi-table joins or distinct tables for each class. Everything seems to work correctly if you use distinct tables for each class. If you are using multi-table joins, however, your objects are not always materialized as the class you would expect. Here is the scenario for the test case I made: Object model - public interface InterfaceA - public class A implements InterfaceA - public class B extends A implements InterfaceA Test case 1 --- - start with a new JVM - select all from extent InterfaceA.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent B.class, loop through and display the class for each Test case 2 --- - restart with a new JVM - select all from extent B.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent InterfaceA.class, loop through and display the class for each Results --- - If using distinct tables for each class (see schema1.sql and repository_user1.xml), both test cases materialize all objects as the correct subclass and returns the expected instances with the appropriate queries. - If using multi-table joins (see schema2.sql and repository_user2.xml), test case 1 displays everything as being class "A", even if it was a "B". Instances of "B" are retrieved and displayed twice in the queries for "InstanceA". Once you get to querying for "B", it turns up absolutely no instances. I imagine this is because it is cached. Test case 2 correctly materializes the objects a "B" and "A", depending on which table they appear in; when you query against InterfaceA.class, however, it still displays the duplicates for instances of "B". For convenience in debugging, I have written a command-line test that lets you choose the order in which the extents are retrieved and displayed. You can run it by doing: java polymorphtest.PolymorphTest 0 1 2 (test case 1) OR java polymorphtest.PolymorphTest 2 1 0 (test case 2) All the related classes, schemas, and O/R mappings are attached to this bug. Please contact me if you need help reproducing the errors. I don't want to send the attachments to the whole list, but I will be glad to email the tarball to whomever requests it. Thanks in advance for your help! Sincerely, Justis Peters Oculan Corp. [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: Wrong class materialized when selecting from an extent mapped to a multi-table join
hi justis, well, but the sample code does NOT show any extents ;) i just installed your testcase and will start digging into it. jakob Justis Peters wrote: Hi Jakob, Thanks for your reply! Yes. What you describe is exactly what I am doing. I have read your discussion with Brendan, and I understand what you are saying. This is in direct conflict with what is implied in "http://db.apache.org/ojb/tutorial3.html";, though. The section titled "mapping classes on multiple joined tables" is located under the section "mapping inheritance hierarchies" and implies that you should be able to treat these items polymorphically. Particularly since it immediately follows the section that explains how to retrieve and handle polymorphic subclasses. In the current version (I am using RC4), I have just accepted that this isn't possible with a class hierarcy that spans multiple tables. My original database design had all the common elements in one table, and used additional tables to add on the information used by subclasses. Fortunately, I can change this (since I own the database). I will change to using a distinct table for each subclass, with all the fields repeated. Inside the database, I will simply create a new view that recreates what I had by having all the common data in one table. IMO, it would be a good feature to allow querying against an extent when your "extended" data is stored in separate tables. If it is not possible to include this, we could at least rewrite the tutorial to more clearly explain that if you select all elements from "org.apache.ojb.broker.A", you will not get any instances of "org.apache.ojb.broker.B", even if the data exists. Thanks again! Justis Peters Oculan Corp. [EMAIL PROTECTED] Jakob Braeuchi [EMAIL PROTECTED] wrote: hi justis, is this another case of mixing extents and 'super'-references ? i had a long offline discussion with brendan regarding this topic: http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3933 http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3920 jakob Justis Peters wrote: Hi All! Just a couple weeks ago I started using OJB, and I am extremely impressed. My gratitude goes to all who put in the work to make it possible. Upon converting some of the more complicated parts of my object model, I encountered a strange issue. Here is the bug I attempted to submit to scarab. Apparently, scarab is having problems. At first, it assigned an ID to my issue that was already assigned to another issue, so I can't retrieve it. Now, it won't let me enter new issues and keeps directing me to the query page isntead. Anyhow, here is the summary of the bug. Any help would be appreciated: ====== When selecting an entire extent from a parent class, the behavior varies depending on whether you are using multi-table joins or distinct tables for each class. Everything seems to work correctly if you use distinct tables for each class. If you are using multi-table joins, however, your objects are not always materialized as the class you would expect. Here is the scenario for the test case I made: Object model - public interface InterfaceA - public class A implements InterfaceA - public class B extends A implements InterfaceA Test case 1 --- - start with a new JVM - select all from extent InterfaceA.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent B.class, loop through and display the class for each Test case 2 --- - restart with a new JVM - select all from extent B.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent InterfaceA.class, loop through and display the class for each Results --- - If using distinct tables for each class (see schema1.sql and repository_user1.xml), both test cases materialize all objects as the correct subclass and returns the expected instances with the appropriate queries. - If using multi-table joins (see schema2.sql and repository_user2.xml), test case 1 displays everything as being class "A", even if it was a "B". Instances of "B" are retrieved and displayed twice in the queries for "InstanceA". Once you get to querying for "B", it turns up absolutely no instances. I imagine this is because it is cached. Test case 2 correctly materializes the objects a "B" and "A", depending on which table they appear in; when you query against InterfaceA.class, however, it still displays the duplicates for instances of "B". For convenience in debugging, I have written a command-line test that lets you choose the order in which the e
Re: Wrong class materialized when selecting from an extent mapped to a multi-table join
Hi Jakob, Thanks for your reply! Yes. What you describe is exactly what I am doing. I have read your discussion with Brendan, and I understand what you are saying. This is in direct conflict with what is implied in "http://db.apache.org/ojb/tutorial3.html";, though. The section titled "mapping classes on multiple joined tables" is located under the section "mapping inheritance hierarchies" and implies that you should be able to treat these items polymorphically. Particularly since it immediately follows the section that explains how to retrieve and handle polymorphic subclasses. In the current version (I am using RC4), I have just accepted that this isn't possible with a class hierarcy that spans multiple tables. My original database design had all the common elements in one table, and used additional tables to add on the information used by subclasses. Fortunately, I can change this (since I own the database). I will change to using a distinct table for each subclass, with all the fields repeated. Inside the database, I will simply create a new view that recreates what I had by having all the common data in one table. IMO, it would be a good feature to allow querying against an extent when your "extended" data is stored in separate tables. If it is not possible to include this, we could at least rewrite the tutorial to more clearly explain that if you select all elements from "org.apache.ojb.broker.A", you will not get any instances of "org.apache.ojb.broker.B", even if the data exists. Thanks again! Justis Peters Oculan Corp. [EMAIL PROTECTED] Jakob Braeuchi [EMAIL PROTECTED] wrote: > hi justis, > > is this another case of mixing extents and 'super'-references ? > i had a long offline discussion with brendan regarding this topic: > > http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3933 > http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3920 > > jakob > > Justis Peters wrote: > > >Hi All! > > > >Just a couple weeks ago I started using OJB, and I am extremely impressed. > >My gratitude goes to all who put in the work to make it possible. > > > >Upon converting some of the more complicated parts of my object model, I > >encountered a strange issue. Here is the bug I attempted to submit to > >scarab. Apparently, scarab is having problems. At first, it assigned an > >ID to my issue that was already assigned to another issue, so I can't > >retrieve it. Now, it won't let me enter new issues and keeps directing me > >to the query page isntead. > > > >Anyhow, here is the summary of the bug. Any help would be appreciated: > > > >== > >When selecting an entire extent from a parent class, the behavior varies > >depending on whether you are using multi-table joins or distinct tables > >for each class. Everything seems to work correctly if you use distinct > >tables for each class. If you are using multi-table joins, however, your > >objects are not always materialized as the class you would expect. Here > >is the scenario for the test case I made: > > > >Object model > > > >- public interface InterfaceA > >- public class A implements InterfaceA > >- public class B extends A implements InterfaceA > > > >Test case 1 > >--- > >- start with a new JVM > >- select all from extent InterfaceA.class, loop through and display the > >class for each > >- select all from extent A.class, loop through and display the class for > >each > >- select all from extent B.class, loop through and display the class for > >each > > > >Test case 2 > >--- > >- restart with a new JVM > >- select all from extent B.class, loop through and display the class for > >each > >- select all from extent A.class, loop through and display the class for > >each > >- select all from extent InterfaceA.class, loop through and display the > >class for each > > > >Results > >--- > >- If using distinct tables for each class (see schema1.sql and > >repository_user1.xml), both test cases materialize all objects as the > >correct subclass and returns the expected instances with the appropriate > >queries. > >- If using multi-table joins (see schema2.sql and repository_user2.xml), > >test case 1 displays everything as being class "A", even if it was a "B". > >Instances of "B" are retrieved and displayed twice in the queries for > >"InstanceA". Once you get to querying for &q
Re: Wrong class materialized when selecting from an extent mapped to a multi-table join
hi wallace, currently there are problems when mixing extents and super-reference. imo it has something to do with Identity and caching. the examples on the website do NOT mix those features. i always regarded multi-table join as a technical feature to support mapping ONE class onto MANY tables. in the repository those class-descriptors are connect using the super-reference. on the java-side inheritance is used and makes people think that they also need extents in the repository. jakob Gelhar, Wallace Joseph wrote: Hi Jakob, Sorry to be chiming in from left field, but does this imply that 'super' references and extents cannot be used together in the same object model? In the same class descriptor? Please explain. Wally -Original Message- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 6:53 AM To: OJB Users List Subject: Re: Wrong class materialized when selecting from an extent mapped to a multi-table join hi justis, is this another case of mixing extents and 'super'-references ? i had a long offline discussion with brendan regarding this topic: http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3933 http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3920 jakob Justis Peters wrote: Hi All! Just a couple weeks ago I started using OJB, and I am extremely impressed. My gratitude goes to all who put in the work to make it possible. Upon converting some of the more complicated parts of my object model, I encountered a strange issue. Here is the bug I attempted to submit to scarab. Apparently, scarab is having problems. At first, it assigned an ID to my issue that was already assigned to another issue, so I can't retrieve it. Now, it won't let me enter new issues and keeps directing me to the query page isntead. Anyhow, here is the summary of the bug. Any help would be appreciated: == When selecting an entire extent from a parent class, the behavior varies depending on whether you are using multi-table joins or distinct tables for each class. Everything seems to work correctly if you use distinct tables for each class. If you are using multi-table joins, however, your objects are not always materialized as the class you would expect. Here is the scenario for the test case I made: Object model - public interface InterfaceA - public class A implements InterfaceA - public class B extends A implements InterfaceA Test case 1 --- - start with a new JVM - select all from extent InterfaceA.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent B.class, loop through and display the class for each Test case 2 --- - restart with a new JVM - select all from extent B.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent InterfaceA.class, loop through and display the class for each Results --- - If using distinct tables for each class (see schema1.sql and repository_user1.xml), both test cases materialize all objects as the correct subclass and returns the expected instances with the appropriate queries. - If using multi-table joins (see schema2.sql and repository_user2.xml), test case 1 displays everything as being class "A", even if it was a "B". Instances of "B" are retrieved and displayed twice in the queries for "InstanceA". Once you get to querying for "B", it turns up absolutely no instances. I imagine this is because it is cached. Test case 2 correctly materializes the objects a "B" and "A", depending on which table they appear in; when you query against InterfaceA.class, however, it still displays the duplicates for instances of "B". For convenience in debugging, I have written a command-line test that lets you choose the order in which the extents are retrieved and displayed. You can run it by doing: java polymorphtest.PolymorphTest 0 1 2 (test case 1) OR java polymorphtest.PolymorphTest 2 1 0 (test case 2) All the related classes, schemas, and O/R mappings are attached to this bug. Please contact me if you need help reproducing the errors. I don't want to send the attachments to the whole list, but I will be glad to email the tarball to whomever requests it. Thanks in advance for your help! Sincerely, Justis Peters Oculan Corp. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --
RE: Wrong class materialized when selecting from an extent mapped to a multi-table join
Hi Jakob, Sorry to be chiming in from left field, but does this imply that 'super' references and extents cannot be used together in the same object model? In the same class descriptor? Please explain. Wally -Original Message- From: Jakob Braeuchi [mailto:[EMAIL PROTECTED] Sent: Friday, October 17, 2003 6:53 AM To: OJB Users List Subject: Re: Wrong class materialized when selecting from an extent mapped to a multi-table join hi justis, is this another case of mixing extents and 'super'-references ? i had a long offline discussion with brendan regarding this topic: http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3933 http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3920 jakob Justis Peters wrote: > Hi All! > > Just a couple weeks ago I started using OJB, and I am extremely > impressed. My gratitude goes to all who put in the work to make it > possible. > > Upon converting some of the more complicated parts of my object model, > I encountered a strange issue. Here is the bug I attempted to submit > to scarab. Apparently, scarab is having problems. At first, it > assigned an ID to my issue that was already assigned to another issue, > so I can't retrieve it. Now, it won't let me enter new issues and > keeps directing me to the query page isntead. > > Anyhow, here is the summary of the bug. Any help would be > appreciated: > > == > > When selecting an entire extent from a parent class, the behavior varies depending on whether you are using multi-table joins or distinct tables for each class. Everything seems to work correctly if you use distinct tables for each class. If you are using multi-table joins, however, your objects are not always materialized as the class you would expect. Here is the scenario for the test case I made: > > Object model > > - public interface InterfaceA > - public class A implements InterfaceA > - public class B extends A implements InterfaceA > > Test case 1 > --- > - start with a new JVM > - select all from extent InterfaceA.class, loop through and display > the class for each > - select all from extent A.class, loop through and display the class for each > - select all from extent B.class, loop through and display the class for each > > Test case 2 > --- > - restart with a new JVM > - select all from extent B.class, loop through and display the class > for each > - select all from extent A.class, loop through and display the class for each > - select all from extent InterfaceA.class, loop through and display the class for each > > Results > --- > - If using distinct tables for each class (see schema1.sql and > repository_user1.xml), both test cases materialize all objects as the correct subclass and returns the expected instances with the appropriate queries. > - If using multi-table joins (see schema2.sql and repository_user2.xml), test case 1 displays everything as being class "A", even if it was a "B". Instances of "B" are retrieved and displayed twice in the queries for "InstanceA". Once you get to querying for "B", it turns up absolutely no instances. I imagine this is because it is cached. Test case 2 correctly materializes the objects a "B" and "A", depending on which table they appear in; when you query against InterfaceA.class, however, it still displays the duplicates for instances of "B". > > > For convenience in debugging, I have written a command-line test that lets you choose the order in which the extents are retrieved and displayed. You can run it by doing: > java polymorphtest.PolymorphTest 0 1 2 (test case 1) > OR > java polymorphtest.PolymorphTest 2 1 0 (test case 2) > > > All the related classes, schemas, and O/R mappings are attached to > this bug. Please contact me if you need help reproducing the errors. > > > > I don't want to send the attachments to the whole list, but I will be > glad to email the tarball to whomever requests it. Thanks in advance > for your help! > > Sincerely, > Justis Peters > Oculan Corp. > [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: Wrong class materialized when selecting from an extent mapped to a multi-table join
hi justis, please send me your testcase. jakob Justis Peters wrote: Hi All! Just a couple weeks ago I started using OJB, and I am extremely impressed. My gratitude goes to all who put in the work to make it possible. Upon converting some of the more complicated parts of my object model, I encountered a strange issue. Here is the bug I attempted to submit to scarab. Apparently, scarab is having problems. At first, it assigned an ID to my issue that was already assigned to another issue, so I can't retrieve it. Now, it won't let me enter new issues and keeps directing me to the query page isntead. Anyhow, here is the summary of the bug. Any help would be appreciated: == When selecting an entire extent from a parent class, the behavior varies depending on whether you are using multi-table joins or distinct tables for each class. Everything seems to work correctly if you use distinct tables for each class. If you are using multi-table joins, however, your objects are not always materialized as the class you would expect. Here is the scenario for the test case I made: Object model - public interface InterfaceA - public class A implements InterfaceA - public class B extends A implements InterfaceA Test case 1 --- - start with a new JVM - select all from extent InterfaceA.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent B.class, loop through and display the class for each Test case 2 --- - restart with a new JVM - select all from extent B.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent InterfaceA.class, loop through and display the class for each Results --- - If using distinct tables for each class (see schema1.sql and repository_user1.xml), both test cases materialize all objects as the correct subclass and returns the expected instances with the appropriate queries. - If using multi-table joins (see schema2.sql and repository_user2.xml), test case 1 displays everything as being class "A", even if it was a "B". Instances of "B" are retrieved and displayed twice in the queries for "InstanceA". Once you get to querying for "B", it turns up absolutely no instances. I imagine this is because it is cached. Test case 2 correctly materializes the objects a "B" and "A", depending on which table they appear in; when you query against InterfaceA.class, however, it still displays the duplicates for instances of "B". For convenience in debugging, I have written a command-line test that lets you choose the order in which the extents are retrieved and displayed. You can run it by doing: java polymorphtest.PolymorphTest 0 1 2 (test case 1) OR java polymorphtest.PolymorphTest 2 1 0 (test case 2) All the related classes, schemas, and O/R mappings are attached to this bug. Please contact me if you need help reproducing the errors. I don't want to send the attachments to the whole list, but I will be glad to email the tarball to whomever requests it. Thanks in advance for your help! Sincerely, Justis Peters Oculan Corp. [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: Wrong class materialized when selecting from an extent mapped to a multi-table join
hi justis, is this another case of mixing extents and 'super'-references ? i had a long offline discussion with brendan regarding this topic: http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3933 http://article.gmane.org/gmane.comp.jakarta.ojb.devel/3920 jakob Justis Peters wrote: Hi All! Just a couple weeks ago I started using OJB, and I am extremely impressed. My gratitude goes to all who put in the work to make it possible. Upon converting some of the more complicated parts of my object model, I encountered a strange issue. Here is the bug I attempted to submit to scarab. Apparently, scarab is having problems. At first, it assigned an ID to my issue that was already assigned to another issue, so I can't retrieve it. Now, it won't let me enter new issues and keeps directing me to the query page isntead. Anyhow, here is the summary of the bug. Any help would be appreciated: == When selecting an entire extent from a parent class, the behavior varies depending on whether you are using multi-table joins or distinct tables for each class. Everything seems to work correctly if you use distinct tables for each class. If you are using multi-table joins, however, your objects are not always materialized as the class you would expect. Here is the scenario for the test case I made: Object model - public interface InterfaceA - public class A implements InterfaceA - public class B extends A implements InterfaceA Test case 1 --- - start with a new JVM - select all from extent InterfaceA.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent B.class, loop through and display the class for each Test case 2 --- - restart with a new JVM - select all from extent B.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent InterfaceA.class, loop through and display the class for each Results --- - If using distinct tables for each class (see schema1.sql and repository_user1.xml), both test cases materialize all objects as the correct subclass and returns the expected instances with the appropriate queries. - If using multi-table joins (see schema2.sql and repository_user2.xml), test case 1 displays everything as being class "A", even if it was a "B". Instances of "B" are retrieved and displayed twice in the queries for "InstanceA". Once you get to querying for "B", it turns up absolutely no instances. I imagine this is because it is cached. Test case 2 correctly materializes the objects a "B" and "A", depending on which table they appear in; when you query against InterfaceA.class, however, it still displays the duplicates for instances of "B". For convenience in debugging, I have written a command-line test that lets you choose the order in which the extents are retrieved and displayed. You can run it by doing: java polymorphtest.PolymorphTest 0 1 2 (test case 1) OR java polymorphtest.PolymorphTest 2 1 0 (test case 2) All the related classes, schemas, and O/R mappings are attached to this bug. Please contact me if you need help reproducing the errors. I don't want to send the attachments to the whole list, but I will be glad to email the tarball to whomever requests it. Thanks in advance for your help! Sincerely, Justis Peters Oculan Corp. [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]
Wrong class materialized when selecting from an extent mapped to a multi-table join
Hi All! Just a couple weeks ago I started using OJB, and I am extremely impressed. My gratitude goes to all who put in the work to make it possible. Upon converting some of the more complicated parts of my object model, I encountered a strange issue. Here is the bug I attempted to submit to scarab. Apparently, scarab is having problems. At first, it assigned an ID to my issue that was already assigned to another issue, so I can't retrieve it. Now, it won't let me enter new issues and keeps directing me to the query page isntead. Anyhow, here is the summary of the bug. Any help would be appreciated: == When selecting an entire extent from a parent class, the behavior varies depending on whether you are using multi-table joins or distinct tables for each class. Everything seems to work correctly if you use distinct tables for each class. If you are using multi-table joins, however, your objects are not always materialized as the class you would expect. Here is the scenario for the test case I made: Object model - public interface InterfaceA - public class A implements InterfaceA - public class B extends A implements InterfaceA Test case 1 --- - start with a new JVM - select all from extent InterfaceA.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent B.class, loop through and display the class for each Test case 2 --- - restart with a new JVM - select all from extent B.class, loop through and display the class for each - select all from extent A.class, loop through and display the class for each - select all from extent InterfaceA.class, loop through and display the class for each Results --- - If using distinct tables for each class (see schema1.sql and repository_user1.xml), both test cases materialize all objects as the correct subclass and returns the expected instances with the appropriate queries. - If using multi-table joins (see schema2.sql and repository_user2.xml), test case 1 displays everything as being class "A", even if it was a "B". Instances of "B" are retrieved and displayed twice in the queries for "InstanceA". Once you get to querying for "B", it turns up absolutely no instances. I imagine this is because it is cached. Test case 2 correctly materializes the objects a "B" and "A", depending on which table they appear in; when you query against InterfaceA.class, however, it still displays the duplicates for instances of "B". For convenience in debugging, I have written a command-line test that lets you choose the order in which the extents are retrieved and displayed. You can run it by doing: java polymorphtest.PolymorphTest 0 1 2 (test case 1) OR java polymorphtest.PolymorphTest 2 1 0 (test case 2) All the related classes, schemas, and O/R mappings are attached to this bug. Please contact me if you need help reproducing the errors. I don't want to send the attachments to the whole list, but I will be glad to email the tarball to whomever requests it. Thanks in advance for your help! Sincerely, Justis Peters Oculan Corp. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: select all from extent?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
select all from extent?
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent problem with multiple classes and tables
hi cesar,
please have a look at my post in the developer-list
'PersistenceBrokerImpl#storeToDb (assigning reference fk)'
jakob
Cesar wrote:
Hi Christopher
When will you put this correction in the CVS?
[ ]´s
Cesar
- Original Message -
From: "Christopher C Worley" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, September 17, 2003 5:40 PM
Subject: Re: Extent problem with multiple classes and tables
Jakob,
After looking at you test case in noticed I was not using anonymous
fields to represent my fk to the super class. I changed my code to do
this and it works fine. Is this the way it should be done?
The only question i have is how do i get my pk to go in order. it
appears all three tables use the same sequence name.
-chris worley
hi christopher,
i had to remove the patch becaus of stack overflow and other errors.
jakob
Jakob Braeuchi wrote:
hi christopher,
thanks for the patch.
i checked it in and also added new testcases in class
AnonymousFieldsTest to verify multilevel vertical inheritance.
jakob
Christopher C Worley wrote:
I have finnaly found a solution to the problem with mapping more
than two classes to multiple joined tables.
Currently an exception occures becuase no primary key has been
assinged to class A which does have the auto increment set to true.
The reason is ojb only follows the hierarchy up one level. Which is
why two class work fine. To solve the problem i added
assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors()) to
PersistenceBrokerImpl.assertFkAssignment(...).
--- Begin Code --
if (ref == null)
{
refPkValues = new Object[objFkFields.length];
}
else
{
// BRJ: ref may be Proxy
Class refClass = ProxyHelper.getRealClass(ref);
ClassDescriptor refCld =
descriptorRepository.getDescriptorFor(refClass);
// Add this line to assign reference FKs
assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors());
refPkValues = brokerHelper.getKeyValues(refCld, ref, false);
}
--- End Code --
The test cases for 1.0rc4 passed with this line. Could sombody
review this and get a fix into cvs.
-chris worley
Oliver,
Below is an example of my reposity.
if i call broker.store(B) bother records for A and B get created
fine. When I store C I get a message saying pk is not valid for
C. I think when validating the PK for see it should get the
auto-increment from A, but it does not. If i set the pk myself it
exceptions out trying to add null value to C.id which is odd. If i
set auto-increment=true on B then all three classes get store but
with different pk's.
7 WARN [main] root -
org.apache.ojb.broker.PersistenceBrokerException:
assertValidPkFields failed for Object of type: C on insert
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown
Source)
---
Hello Chris,
-Original Message-
From: Christopher C Worley [mailto:[EMAIL PROTECTED]
Still having problems with this. I have a question about
defining extents. In the below explination would C be the only
class I would have to define the extent classes for or would it
be in A?
In the situation C extends B extends A you need:
I have been successfull at handling mapping extents (two classes
to two tables). Whe I add a third class I get
"assertValidPkFields failed for Object of type..." error.
What is the precise message text?
is null so it updates the referenceFKs. When it does this it
only looks at the B reference which is null. So, I get this
error. I
Which B reference?
Can you explain more detailed?
Olli
-
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: Extent problem with multiple classes and tables
Hi Christopher
When will you put this correction in the CVS?
[ ]´s
Cesar
- Original Message -
From: "Christopher C Worley" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Wednesday, September 17, 2003 5:40 PM
Subject: Re: Extent problem with multiple classes and tables
> Jakob,
>
> After looking at you test case in noticed I was not using anonymous
> fields to represent my fk to the super class. I changed my code to do
> this and it works fine. Is this the way it should be done?
>
> The only question i have is how do i get my pk to go in order. it
> appears all three tables use the same sequence name.
>
> -chris worley
>
> > hi christopher,
> >
> > i had to remove the patch becaus of stack overflow and other errors.
> >
> > jakob
> >
> > Jakob Braeuchi wrote:
> >
> >> hi christopher,
> >>
> >> thanks for the patch.
> >> i checked it in and also added new testcases in class
> >> AnonymousFieldsTest to verify multilevel vertical inheritance.
> >>
> >> jakob
> >>
> >> Christopher C Worley wrote:
> >>
> >>>
> >>> I have finnaly found a solution to the problem with mapping more
> >>> than two classes to multiple joined tables.
> >>> Currently an exception occures becuase no primary key has been
> >>> assinged to class A which does have the auto increment set to true.
> >>> The reason is ojb only follows the hierarchy up one level. Which is
> >>> why two class work fine. To solve the problem i added
> >>> assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors()) to
> >>> PersistenceBrokerImpl.assertFkAssignment(...).
> >>>
> >>> --- Begin Code --
> >>> if (ref == null)
> >>> {
> >>> refPkValues = new Object[objFkFields.length];
> >>> }
> >>> else
> >>> {
> >>> // BRJ: ref may be Proxy
> >>> Class refClass = ProxyHelper.getRealClass(ref);
> >>> ClassDescriptor refCld =
> >>> descriptorRepository.getDescriptorFor(refClass);
> >>>
> >>> // Add this line to assign reference FKs
> >>> assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors());
> >>> refPkValues = brokerHelper.getKeyValues(refCld, ref, false);
> >>> }
> >>> --- End Code --
> >>>
> >>> The test cases for 1.0rc4 passed with this line. Could sombody
> >>> review this and get a fix into cvs.
> >>>
> >>> -chris worley
> >>>
> >>>> Oliver,
> >>>>
> >>>> Below is an example of my reposity.
> >>>> if i call broker.store(B) bother records for A and B get created
> >>>> fine. When I store C I get a message saying pk is not valid for
> >>>> C. I think when validating the PK for see it should get the
> >>>> auto-increment from A, but it does not. If i set the pk myself it
> >>>> exceptions out trying to add null value to C.id which is odd. If i
> >>>> set auto-increment=true on B then all three classes get store but
> >>>> with different pk's.
> >>>>
> >>>> 7 WARN [main] root -
> >>>> org.apache.ojb.broker.PersistenceBrokerException:
> >>>> assertValidPkFields failed for Object of type: C on insert
> >>>>at
> >>>> org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown
> >>>> Source)
> >>>>
> >>>>
> >>>> ---
> >>>>
> >>>> >>>>class="A"
> >>>>table="A_TABLE"
> >>>>>
> >>>> >>>>name="Id"
> >>>>column="ID"
> >>>>jdbc-type="INTEGER"
> >>>>primarykey="true"
> >>>>autoincrement="true"
> >>>>/>
> >>>> >>>>name="aValue"
> >>>>column="A_VALUE"
> >>>>jdbc-type="VARCHAR"
> >>>>/>
> >>>>
> >>>>
> >>>> >>&
Re: Extent problem with multiple classes and tables
Jakob,
After looking at you test case in noticed I was not using anonymous
fields to represent my fk to the super class. I changed my code to do
this and it works fine. Is this the way it should be done?
The only question i have is how do i get my pk to go in order. it
appears all three tables use the same sequence name.
-chris worley
hi christopher,
i had to remove the patch becaus of stack overflow and other errors.
jakob
Jakob Braeuchi wrote:
hi christopher,
thanks for the patch.
i checked it in and also added new testcases in class
AnonymousFieldsTest to verify multilevel vertical inheritance.
jakob
Christopher C Worley wrote:
I have finnaly found a solution to the problem with mapping more
than two classes to multiple joined tables.
Currently an exception occures becuase no primary key has been
assinged to class A which does have the auto increment set to true.
The reason is ojb only follows the hierarchy up one level. Which is
why two class work fine. To solve the problem i added
assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors()) to
PersistenceBrokerImpl.assertFkAssignment(...).
--- Begin Code --
if (ref == null)
{
refPkValues = new Object[objFkFields.length];
}
else
{
// BRJ: ref may be Proxy
Class refClass = ProxyHelper.getRealClass(ref);
ClassDescriptor refCld =
descriptorRepository.getDescriptorFor(refClass);
// Add this line to assign reference FKs
assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors());
refPkValues = brokerHelper.getKeyValues(refCld, ref, false);
}
--- End Code --
The test cases for 1.0rc4 passed with this line. Could sombody
review this and get a fix into cvs.
-chris worley
Oliver,
Below is an example of my reposity.
if i call broker.store(B) bother records for A and B get created
fine. When I store C I get a message saying pk is not valid for
C. I think when validating the PK for see it should get the
auto-increment from A, but it does not. If i set the pk myself it
exceptions out trying to add null value to C.id which is odd. If i
set auto-increment=true on B then all three classes get store but
with different pk's.
7 WARN [main] root -
org.apache.ojb.broker.PersistenceBrokerException:
assertValidPkFields failed for Object of type: C on insert
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown
Source)
---
Hello Chris,
-Original Message-
From: Christopher C Worley [mailto:[EMAIL PROTECTED]
Still having problems with this. I have a question about
defining extents. In the below explination would C be the only
class I would have to define the extent classes for or would it
be in A?
In the situation C extends B extends A you need:
I have been successfull at handling mapping extents (two classes
to two tables). Whe I add a third class I get
"assertValidPkFields failed for Object of type..." error.
What is the precise message text?
is null so it updates the referenceFKs. When it does this it
only looks at the B reference which is null. So, I get this
error. I
Which B reference?
Can you explain more detailed?
Olli
-
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: Extent problem with multiple classes and tables
hi christopher,
i had to remove the patch becaus of stack overflow and other errors.
jakob
Jakob Braeuchi wrote:
hi christopher,
thanks for the patch.
i checked it in and also added new testcases in class
AnonymousFieldsTest to verify multilevel vertical inheritance.
jakob
Christopher C Worley wrote:
I have finnaly found a solution to the problem with mapping more than
two classes to multiple joined tables.
Currently an exception occures becuase no primary key has been
assinged to class A which does have the auto increment set to true.
The reason is ojb only follows the hierarchy up one level. Which is
why two class work fine. To solve the problem i added
assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors()) to
PersistenceBrokerImpl.assertFkAssignment(...).
--- Begin Code --
if (ref == null)
{
refPkValues = new Object[objFkFields.length];
}
else
{
// BRJ: ref may be Proxy
Class refClass = ProxyHelper.getRealClass(ref);
ClassDescriptor refCld =
descriptorRepository.getDescriptorFor(refClass);
// Add this line to assign reference FKs
assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors());
refPkValues = brokerHelper.getKeyValues(refCld, ref, false);
}
--- End Code --
The test cases for 1.0rc4 passed with this line. Could sombody
review this and get a fix into cvs.
-chris worley
Oliver,
Below is an example of my reposity.
if i call broker.store(B) bother records for A and B get created
fine. When I store C I get a message saying pk is not valid for C.
I think when validating the PK for see it should get the
auto-increment from A, but it does not. If i set the pk myself it
exceptions out trying to add null value to C.id which is odd. If i
set auto-increment=true on B then all three classes get store but
with different pk's.
7 WARN [main] root -
org.apache.ojb.broker.PersistenceBrokerException:
assertValidPkFields failed for Object of type: C on insert
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown
Source)
---
Hello Chris,
-Original Message-
From: Christopher C Worley [mailto:[EMAIL PROTECTED]
Still having problems with this. I have a question about defining
extents. In the below explination would C be the only class I
would have to define the extent classes for or would it be in A?
In the situation C extends B extends A you need:
I have been successfull at handling mapping extents (two classes
to two tables). Whe I add a third class I get
"assertValidPkFields failed for Object of type..." error.
What is the precise message text?
is null so it updates the referenceFKs. When it does this it
only looks at the B reference which is null. So, I get this
error. I
Which B reference?
Can you explain more detailed?
Olli
-
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: Extent problem with multiple classes and tables
hi christopher,
thanks for the patch.
i checked it in and also added new testcases in class
AnonymousFieldsTest to verify multilevel vertical inheritance.
jakob
Christopher C Worley wrote:
I have finnaly found a solution to the problem with mapping more than
two classes to multiple joined tables.
Currently an exception occures becuase no primary key has been
assinged to class A which does have the auto increment set to true.
The reason is ojb only follows the hierarchy up one level. Which is
why two class work fine. To solve the problem i added
assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors()) to
PersistenceBrokerImpl.assertFkAssignment(...).
--- Begin Code --
if (ref == null)
{
refPkValues = new Object[objFkFields.length];
}
else
{
// BRJ: ref may be Proxy
Class refClass = ProxyHelper.getRealClass(ref);
ClassDescriptor refCld =
descriptorRepository.getDescriptorFor(refClass);
// Add this line to assign reference FKs
assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors());
refPkValues = brokerHelper.getKeyValues(refCld, ref, false);
}
--- End Code --
The test cases for 1.0rc4 passed with this line. Could sombody review
this and get a fix into cvs.
-chris worley
Oliver,
Below is an example of my reposity.
if i call broker.store(B) bother records for A and B get created
fine. When I store C I get a message saying pk is not valid for C.
I think when validating the PK for see it should get the
auto-increment from A, but it does not. If i set the pk myself it
exceptions out trying to add null value to C.id which is odd. If i
set auto-increment=true on B then all three classes get store but
with different pk's.
7 WARN [main] root -
org.apache.ojb.broker.PersistenceBrokerException: assertValidPkFields
failed for Object of type: C on insert
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown
Source)
---
Hello Chris,
-Original Message-
From: Christopher C Worley [mailto:[EMAIL PROTECTED]
Still having problems with this. I have a question about defining
extents. In the below explination would C be the only class I
would have to define the extent classes for or would it be in A?
In the situation C extends B extends A you need:
I have been successfull at handling mapping extents (two classes
to two tables). Whe I add a third class I get
"assertValidPkFields failed for Object of type..." error.
What is the precise message text?
is null so it updates the referenceFKs. When it does this it only
looks at the B reference which is null. So, I get this error. I
Which B reference?
Can you explain more detailed?
Olli
-
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: Extent problem with multiple classes and tables
I have finnaly found a solution to the problem with mapping more than
two classes to multiple joined tables.
Currently an exception occures becuase no primary key has been assinged
to class A which does have the auto increment set to true. The reason
is ojb only follows the hierarchy up one level. Which is why two class
work fine. To solve the problem i added assignReferenceFKs(ref,
refCld.getObjectReferenceDescriptors()) to
PersistenceBrokerImpl.assertFkAssignment(...).
--- Begin Code --
if (ref == null)
{
refPkValues = new Object[objFkFields.length];
}
else
{
// BRJ: ref may be Proxy
Class refClass = ProxyHelper.getRealClass(ref);
ClassDescriptor refCld = descriptorRepository.getDescriptorFor(refClass);
// Add this line to assign reference FKs
assignReferenceFKs(ref, refCld.getObjectReferenceDescriptors());
refPkValues = brokerHelper.getKeyValues(refCld, ref, false);
}
--- End Code --
The test cases for 1.0rc4 passed with this line. Could sombody review
this and get a fix into cvs.
-chris worley
Oliver,
Below is an example of my reposity.
if i call broker.store(B) bother records for A and B get created
fine. When I store C I get a message saying pk is not valid for C. I
think when validating the PK for see it should get the auto-increment
from A, but it does not. If i set the pk myself it exceptions out
trying to add null value to C.id which is odd. If i set
auto-increment=true on B then all three classes get store but with
different pk's.
7 WARN [main] root -
org.apache.ojb.broker.PersistenceBrokerException: assertValidPkFields
failed for Object of type: C on insert
at
org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown
Source)
---
Hello Chris,
-Original Message-
From: Christopher C Worley [mailto:[EMAIL PROTECTED]
Still having problems with this. I have a question about defining
extents. In the below explination would C be the only class I would
have to define the extent classes for or would it be in A?
In the situation C extends B extends A you need:
I have been successfull at handling mapping extents (two classes to
two tables). Whe I add a third class I get "assertValidPkFields
failed for Object of type..." error.
What is the precise message text?
is null so it updates the referenceFKs. When it does this it only
looks at the B reference which is null. So, I get this error. I
Which B reference?
Can you explain more detailed?
Olli
-
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: Extent problem with multiple classes and tables
As I personally don't use joined tables for inheritance mapping, I can't help you much further. However, I'd suggest two things: * Check the unit tests that come with OJB. There is at least one set of tests that deal with joined tables, namely tests that work with org.apache.ojb.broker.E and org.apache.ojb.broker.F. Perhaps you will find some info there. * If the above doesn't solve your problem then please isolate your problem and post a test case that shows it. This will make the removal of possible bugs a lot easier and faster. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent problem with multiple classes and tables
Thomas, Still get same error when trying this. I have looked over the example. The example for multiple classes to multiple tables does not work as written. B should not have autoincrement and it should have auto-update="true" for the reference to A. Other than that it works fine for two classes, I tried what you suggested and it still breaks. I think when the broker sets the FK references in C when I store it. It sets the refernce for B, which will be null since B does not have autoincrement. Then i get this error because the pk is null. If it also set the FK references for B, then the PK in A would get set with autoincrement resulting in the B and C getting set. -chris worley The extent-class tag specifies the persistent subclasses of a class. So if you have class A, class B as a subclass of A, and class C as a subclass of B, then you would write: Note that this other way around from how you specify it in Java (class C extends B, class B extends A). For details see the tutorial at http://db.apache.org/ojb/tutorial3.html#extents%20and%20polymorphism. Tom - 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: Extent problem with multiple classes and tables
Hello again, > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > In the situation C extends B extends A you need: > > > > > > > > oops, as Thomas pointed out, it's the other way round: Silly me, sorry for the confusion. Olli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent problem with multiple classes and tables
The extent-class tag specifies the persistent subclasses of a class. So if you have class A, class B as a subclass of A, and class C as a subclass of B, then you would write: Note that this other way around from how you specify it in Java (class C extends B, class B extends A). For details see the tutorial at http://db.apache.org/ojb/tutorial3.html#extents%20and%20polymorphism. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent problem with multiple classes and tables
Oliver, Below is an example of my reposity. if i call broker.store(B) bother records for A and B get created fine. When I store C I get a message saying pk is not valid for C. I think when validating the PK for see it should get the auto-increment from A, but it does not. If i set the pk myself it exceptions out trying to add null value to C.id which is odd. If i set auto-increment=true on B then all three classes get store but with different pk's. 7 WARN [main] root - org.apache.ojb.broker.PersistenceBrokerException: assertValidPkFields failed for Object of type: C on insert at org.apache.ojb.broker.core.PersistenceBrokerImpl.storeToDb(Unknown Source) --- class="B" table="B_TABLE" > name="Id" column="ID" jdbc-type="INTEGER" primarykey="true" /> name="bValue" column="B_VALUE" jdbc-type="VARCHAR" /> name="super" class-ref="A" auto-update="true" > class="C" table="C_TABLE" > name="Id" column="ID" jdbc-type="INTEGER" primarykey="true" /> name="cValue" column="C_VALUE" jdbc-type="VARCHAR" /> name="super" class-ref="B" auto-update="true" > Hello Chris, -Original Message- From: Christopher C Worley [mailto:[EMAIL PROTECTED] Still having problems with this. I have a question about defining extents. In the below explination would C be the only class I would have to define the extent classes for or would it be in A? In the situation C extends B extends A you need: I have been successfull at handling mapping extents (two classes to two tables). Whe I add a third class I get "assertValidPkFields failed for Object of type..." error. What is the precise message text? is null so it updates the referenceFKs. When it does this it only looks at the B reference which is null. So, I get this error. I Which B reference? Can you explain more detailed? Olli - 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: Extent problem with multiple classes and tables
Hello Chris, > -Original Message- > From: Christopher C Worley [mailto:[EMAIL PROTECTED] > Still having problems with this. I have a question about defining > extents. In the below explination would C be the only class I would > have to define the extent classes for or would it be in A? In the situation C extends B extends A you need: > > > > I have been successfull at handling mapping extents (two classes to > > two tables). Whe I add a third class I get "assertValidPkFields > > failed for Object of type..." error. What is the precise message text? > > is null so it updates the referenceFKs. When it does this it only > > looks at the B reference which is null. So, I get this error. I Which B reference? Can you explain more detailed? Olli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent problem with multiple classes and tables
Still having problems with this. I have a question about defining extents. In the below explination would C be the only class I would have to define the extent classes for or would it be in A? ... -chris worley I have been successfull at handling mapping extents (two classes to two tables). Whe I add a third class I get "assertValidPkFields failed for Object of type..." error. What i have is A -> B -> C. The primary key for A i have setup with autoincrement=true, B and C i do not so i does not screw up the primary keys. I think the problem in PersistenceBrokerImpl.storeToDb() is when it validates the PKs, C.id is null so it updates the referenceFKs. When it does this it only looks at the B reference which is null. So, I get this error. I think it should also set fk references for A, if so then the PK would autoincrement. To test this i also added autoincrement to B class descriptor and i did not get this error; however, my PK's where wrong because A also autoincremented. Is there somthing else i need to set in my class descriptors. -chris worley - 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: Extent Problem
Thomas, Thanks for the reply. I was able to get it to work by adding auto-update=true to the B's reference descriptor for A. I am having another problem when I try to do this with 3 classes. I have the problem in a nother thread on the mailing list if you could look at it for me. -chris worley > Hi Christopher, > > Christopher C Worley wrote: >> >> Is it possible for ojb to insert records for both classes involved in an >> extent? > > Yes, that's possible, I think there are also use cases testing the > insert into multiple tables. > >> I have the classes mapped as they are in this example >> (http://db.apache.org/ojb/tutorial3.html#mapping%20classes%20on%20multiple%20joined%20tables). >> The problem i am having is that B gets stored and no record for A. > > Mhh, that's strange... I think there is a problem with your > repository.xml. > Could you please post the relevant sections of your persistent classes > and the repository entries? > >> Also, i noticed that the primary key for B skips each time as if A has >> also generated a key. > > That's the expected behaviour. The sequence manager maintains unique > primary key values across all classes in an extent. This is done to > avoid to have two objects belomging to the same extent in two tables > that share the same PK. > > cheers, > Thomas > >> -chris worley >> >> >> - >> 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: Extent Problem
Hi Christopher, Christopher C Worley wrote: Is it possible for ojb to insert records for both classes involved in an extent? Yes, that's possible, I think there are also use cases testing the insert into multiple tables. I have the classes mapped as they are in this example (http://db.apache.org/ojb/tutorial3.html#mapping%20classes%20on%20multiple%20joined%20tables). The problem i am having is that B gets stored and no record for A. Mhh, that's strange... I think there is a problem with your repository.xml. Could you please post the relevant sections of your persistent classes and the repository entries? Also, i noticed that the primary key for B skips each time as if A has also generated a key. That's the expected behaviour. The sequence manager maintains unique primary key values across all classes in an extent. This is done to avoid to have two objects belomging to the same extent in two tables that share the same PK. cheers, Thomas -chris worley - 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]
Extent problem with multiple classes and tables
I have been successfull at handling mapping extents (two classes to two tables). Whe I add a third class I get "assertValidPkFields failed for Object of type..." error. What i have is A -> B -> C. The primary key for A i have setup with autoincrement=true, B and C i do not so i does not screw up the primary keys. I think the problem in PersistenceBrokerImpl.storeToDb() is when it validates the PKs, C.id is null so it updates the referenceFKs. When it does this it only looks at the B reference which is null. So, I get this error. I think it should also set fk references for A, if so then the PK would autoincrement. To test this i also added autoincrement to B class descriptor and i did not get this error; however, my PK's where wrong because A also autoincremented. Is there somthing else i need to set in my class descriptors. -chris worley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent Problem
I can get the record for A inserted into the database if in the reference descriptor i set auto-update="true". However, there still is a problem. The primary key still skips when using autoincrement. I guess i could set it myself. Is this the correct way to handle extents on multiple tables or am I missing somthing? -chris worley Is it possible for ojb to insert records for both classes involved in an extent? I have the classes mapped as they are in this example (http://db.apache.org/ojb/tutorial3.html#mapping%20classes%20on%20multiple%20joined%20tables). The problem i am having is that B gets stored and no record for A. Also, i noticed that the primary key for B skips each time as if A has also generated a key. -chris worley - 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]
Extent Problem
Is it possible for ojb to insert records for both classes involved in an extent? I have the classes mapped as they are in this example (http://db.apache.org/ojb/tutorial3.html#mapping%20classes%20on%20multiple%20joined%20tables). The problem i am having is that B gets stored and no record for A. Also, i noticed that the primary key for B skips each time as if A has also generated a key. -chris worley - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
extent with inheritence using JOIN on multiple tables. bug?
Hello I am trying to use the inheritence implementation with joining multiple tables. It seems to work fine except when I add the "" into the repository.xml for the base class. After adding the extent tag, the original find using the subclass no longer return values for inherited attributes. Furthermore, query by base class returns 2 copies of the data but without being a subclass object. Please look at SimpleWithList, any help would be great! Thanks Ka-Wai class="net.codebasis.ormapping.entity.Simple" table="Simple" > name="id" column="id" jdbc-type="INTEGER" primarykey="true" autoincrement="true" conversion="org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion" /> name="name" column="NAME" jdbc-type="VARCHAR" /> name="value" column="value" jdbc-type="VARCHAR" /> name="lastModifiedUser" column="lmu" jdbc-type="VARCHAR" /> name="lastModifiedDate" column="lmd" jdbc-type="DATE" conversion="org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDateFieldConversion" /> class="net.codebasis.ormapping.entity.Component" table="Component" > name="id" column="id" jdbc-type="INTEGER" primarykey="true" autoincrement="true" conversion="org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion" /> name="value" column="value" jdbc-type="VARCHAR" /> class="net.codebasis.ormapping.entity.SimpleWithComponent" table="SimpleWithComponent" > name="id" column="id" jdbc-type="INTEGER" primarykey="true" autoincrement="true" conversion="org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion" /> name="componentId" column="componentId" jdbc-type="INTEGER" conversion="org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion" /> name="name" column="NAME" jdbc-type="VARCHAR" /> name="value" column="value" jdbc-type="VARCHAR" /> name="lastModifiedUser" column="lmu" jdbc-type="VARCHAR" /> name="lastModifiedDate" column="lmd" jdbc-type="DATE" conversion="org.apache.ojb.broker.accesslayer.conversions.JavaDate2SqlDateFieldConversion" /> name="component" class-ref="net.codebasis.ormapping.entity.Component" auto-retrieve="true" auto-update="true" auto-delete="true" > class="net.codebasis.ormapping.entity.Item" table="Item" > name="id" column="id" jdbc-type="INTEGER" primarykey="true" autoincrement="true" conversion="org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion" /> name="simpleId" column="simpleId" jdbc-type="INTEGER" conversion="org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion" /> name="value" column="value" jdbc-type="VARCHAR" /> class="net.codebasis.ormapping.entity.SimpleWithList" table="SimpleWithList" > name="id" column="id" jdbc-type="INTEGER" primarykey="true" autoincrement="true" conversion="org.apache.ojb.broker.accesslayer.conversions.Int2IntegerFieldConversion" /> - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent. How to?
thanks again.
- Original Message -
From: "Thomas Mahler" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, June 03, 2003 6:19 PM
Subject: Re: Extent. How to?
> Hi again Alen,
>
> try this:
>
>
>
>
> class="za.co.alen.jfaq.User"
>table="User"
>
>
> >
>
>...
>
>
> class="za.co.alen.jfaq.RegisterForm"
>table="User"
> >
>
>...
>
>
> class="za.co.alen.jfaq.LogonForm"
>table="User"
> >
>
>...
>
>
> You should also have a look at the repository_junit.xml, it contains *a
> lot* of inheritance examples!
>
> cheers,
> Thomas
>
>
>
> Alen Ribic wrote:
> > Ok I'm back again on this one.
> > Lets try this again.
> >
> > My objective:
> >
> > Using Struts, I will need to create form bean for each Struts form.
> >
> > So, for example, I will create RegisterForm and LogonForm classes.
> > As you can se now, these two classes will have similarities in their
> > getter/setter methods.
> >
> > Hence I would like to Create a single User class that all these similar
form
> > beans can inherit.
> >
> > public class RegisterForm extends User {
> > // inherits necessary setters/getters from User class
> > public ... validate(...) { // override superclasses version
> > }
> > }
> >
> > public class LogonForm extends User {
> > // inherits necessary setters/getters from User class
> > public ... validate(...) { // override superclasses version
> > }
> > }
> >
> > Now I want my form beans also to inherit ValidatorForm class.
> >
> > So, I add extends on User class as follows: (don't really think this one
is
> > cool, but anyway, it works :) )
> >
> > public class User extends ValidatorForm {
> > // setter/getter properties
> > }
> >
> > As far as Struts side of things, this seems to be working fine so far.
> >
> > Only reason I make use of form classes here that inherit my User class
is
> > because of validation requirements specific to each individual form.
(needed
> > in my Struts config) Now there is no way I'm rewriting my User specific
> > setter/getter properties for each of my forms, e.g. RegisterForm,
LogonForm.
> > Both of these form beans will contain common setter/getter properties
which
> > need to map to the same table called User.
> >
> > Again, if I need to specify for each form bean (RegisterForm, LogonForm)
a
> > separate class descriptor with it's own, SAME, fields, it would just
suck a
> > bit.
> >
> > Hope this time I come roght. :)
> >
> > I really appreciate your help.
> > --Alen
> >
> >
> >
> > - Original Message -
> > From: "Thomas Mahler" <[EMAIL PROTECTED]>
> > To: "OJB Users List" <[EMAIL PROTECTED]>
> > Sent: Tuesday, June 03, 2003 11:43 AM
> > Subject: Re: Extent. How to?
> >
> >
> >
> >>Hi again Alen.
> >>
> >>I think you should define the extent the other way round.
> >>That is: RegisterForm is the abstract base class and User is the
> >>concrete class defining all the persistent attributes.
> >>
> >>
> >>
> >>
> >>
> >> >> class="za.co.alen.jfaq.User"
> >> table="User"
> >>>
> >>
> >> ...
> >>
> >>
> >>cheers,
> >>Thomas
> >>
> >>Alen Ribic wrote:
> >>
> >>>Thanks Raymond for your reply.
> >>>
> >>>This is the thing. I am very lost.
> >>>The User class descriptor in repository contains all my filed mappings
> >
> > to my
> >
> >>>User table in db.
> >>>Now za.co.alen.struts.RegisterForm class mapping is a very good
> >
> > question.
> >
> >>>What would the za.co.alen.struts.RegisterForm class mapping contain? I
> >
> > don't
> >
> >>>need any RegisterForm class specific fields at all.
> >>>I just need to indicate to OJB that it needs to something like cast
> >>>RegisterForm instance to User and hence would need to map that to User
> >
> > class
&
RE: Extent. How to?
It sounds like your over thinking this. I don't think you need *any*
extents. You never query for anything but your concrete class, so only
map the RegisterForm and LogonForm.
BTW...why would you want to persist a struts form-bean anyways?
Wallace J Gelhar
Facilities Planning & Management
Computer Information Systems
[EMAIL PROTECTED]
(715) 836-3411
-Original Message-
From: Thomas Mahler [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 11:19 AM
To: OJB Users List
Subject: Re: Extent. How to?
Hi again Alen,
try this:
>
...
...
...
You should also have a look at the repository_junit.xml, it contains *a
lot* of inheritance examples!
cheers,
Thomas
Alen Ribic wrote:
> Ok I'm back again on this one.
> Lets try this again.
>
> My objective:
>
> Using Struts, I will need to create form bean for each Struts form.
>
> So, for example, I will create RegisterForm and LogonForm classes. As
> you can se now, these two classes will have similarities in their
> getter/setter methods.
>
> Hence I would like to Create a single User class that all these
> similar form beans can inherit.
>
> public class RegisterForm extends User {
> // inherits necessary setters/getters from User class
> public ... validate(...) { // override superclasses version
> }
> }
>
> public class LogonForm extends User {
> // inherits necessary setters/getters from User class
> public ... validate(...) { // override superclasses version
> }
> }
>
> Now I want my form beans also to inherit ValidatorForm class.
>
> So, I add extends on User class as follows: (don't really think this
> one is cool, but anyway, it works :) )
>
> public class User extends ValidatorForm {
> // setter/getter properties
> }
>
> As far as Struts side of things, this seems to be working fine so far.
>
> Only reason I make use of form classes here that inherit my User class
> is because of validation requirements specific to each individual
> form. (needed in my Struts config) Now there is no way I'm rewriting
> my User specific setter/getter properties for each of my forms, e.g.
> RegisterForm, LogonForm. Both of these form beans will contain common
> setter/getter properties which need to map to the same table called
> User.
>
> Again, if I need to specify for each form bean (RegisterForm,
> LogonForm) a separate class descriptor with it's own, SAME, fields, it
> would just suck a bit.
>
> Hope this time I come roght. :)
>
> I really appreciate your help.
> --Alen
>
>
>
> - Original Message -
> From: "Thomas Mahler" <[EMAIL PROTECTED]>
> To: "OJB Users List" <[EMAIL PROTECTED]>
> Sent: Tuesday, June 03, 2003 11:43 AM
> Subject: Re: Extent. How to?
>
>
>
>>Hi again Alen.
>>
>>I think you should define the extent the other way round. That is:
>>RegisterForm is the abstract base class and User is the concrete class
>>defining all the persistent attributes.
>>
>>
>>
>>
>>
>>> class="za.co.alen.jfaq.User"
>> table="User"
>>>
>>
>> ...
>>
>>
>>cheers,
>>Thomas
>>
>>Alen Ribic wrote:
>>
>>>Thanks Raymond for your reply.
>>>
>>>This is the thing. I am very lost.
>>>The User class descriptor in repository contains all my filed
>>>mappings
>
> to my
>
>>>User table in db.
>>>Now za.co.alen.struts.RegisterForm class mapping is a very good
>
> question.
>
>>>What would the za.co.alen.struts.RegisterForm class mapping contain?
>>>I
>
> don't
>
>>>need any RegisterForm class specific fields at all.
>>>I just need to indicate to OJB that it needs to something like cast
>>>RegisterForm instance to User and hence would need to map that to
>>>User
>
> class
>
>>>/ table mapping. (Remember that the instance I get is of
>>>za.co.alen.struts.RegisterForm)
>>>RegisterForm class does not have any real meaning for persistence
>
> besides
>
>>>the inherited fields from User bean.
>>>It basically just contains overridden validate(...) method used for
>>>server-side validation in my struts components.
>>>
>>>I hope this is making sense. :-)
>>>
>>>--Alen
>>>
>>>
>>>
>>>- Original Message -
>>>From: "Raymond B
Re: Extent. How to?
Hi again Alen,
try this:
>
...
...
...
You should also have a look at the repository_junit.xml, it contains *a
lot* of inheritance examples!
cheers,
Thomas
Alen Ribic wrote:
Ok I'm back again on this one.
Lets try this again.
My objective:
Using Struts, I will need to create form bean for each Struts form.
So, for example, I will create RegisterForm and LogonForm classes.
As you can se now, these two classes will have similarities in their
getter/setter methods.
Hence I would like to Create a single User class that all these similar form
beans can inherit.
public class RegisterForm extends User {
// inherits necessary setters/getters from User class
public ... validate(...) { // override superclasses version
}
}
public class LogonForm extends User {
// inherits necessary setters/getters from User class
public ... validate(...) { // override superclasses version
}
}
Now I want my form beans also to inherit ValidatorForm class.
So, I add extends on User class as follows: (don't really think this one is
cool, but anyway, it works :) )
public class User extends ValidatorForm {
// setter/getter properties
}
As far as Struts side of things, this seems to be working fine so far.
Only reason I make use of form classes here that inherit my User class is
because of validation requirements specific to each individual form. (needed
in my Struts config) Now there is no way I'm rewriting my User specific
setter/getter properties for each of my forms, e.g. RegisterForm, LogonForm.
Both of these form beans will contain common setter/getter properties which
need to map to the same table called User.
Again, if I need to specify for each form bean (RegisterForm, LogonForm) a
separate class descriptor with it's own, SAME, fields, it would just suck a
bit.
Hope this time I come roght. :)
I really appreciate your help.
--Alen
- Original Message -
From: "Thomas Mahler" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, June 03, 2003 11:43 AM
Subject: Re: Extent. How to?
Hi again Alen.
I think you should define the extent the other way round.
That is: RegisterForm is the abstract base class and User is the
concrete class defining all the persistent attributes.
...
cheers,
Thomas
Alen Ribic wrote:
Thanks Raymond for your reply.
This is the thing. I am very lost.
The User class descriptor in repository contains all my filed mappings
to my
User table in db.
Now za.co.alen.struts.RegisterForm class mapping is a very good
question.
What would the za.co.alen.struts.RegisterForm class mapping contain? I
don't
need any RegisterForm class specific fields at all.
I just need to indicate to OJB that it needs to something like cast
RegisterForm instance to User and hence would need to map that to User
class
/ table mapping. (Remember that the instance I get is of
za.co.alen.struts.RegisterForm)
RegisterForm class does not have any real meaning for persistence
besides
the inherited fields from User bean.
It basically just contains overridden validate(...) method used for
server-side validation in my struts components.
I hope this is making sense. :-)
--Alen
- Original Message -
From: "Raymond Barlow" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, June 03, 2003 10:45 AM
Subject: Re: Extent. How to?
Hi Alen
I hate to ask the obvious, but you never know :)
Have you created a mapping for za.co.alen.struts.RegisterForm in your
repository_user.xml file??
Regards,
Raymond Barlow
Alen Ribic wrote:
Hi again
I have sent an email already and got a good reply, but now I have an
issue
with mapping side.
I have got classes as follows:
// JavaBean
public class User extends ValidatorForm {}
// Struts form bean
public class RegisterForm extends User {}
Now I just need OJB to recognize RegisteForm class as a User.
usr = request.getAttribute("registerForm"); // returns RegisteForm
instance
broker.store(usr);
So now, OJB on store(...) should look at mapping for User class to User
table.
...
I presume that now I need a for the RegisterForm
class.
Is this correct?
I looked at the Article example but I just can't get my one to work.
My app still says that OJB cannot recognize RegisterForm class in
repository.
What am I doing wrong and how can I go about doing this correctly.
Thanks
--Alen
-
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: Extent. How to?
Hi Alen,
To me, this just sounds like a design issue. The persistent class is
User, right? I feel that that is the only class out of the 3 classes you
mentioned that should be OJB controlled. Like I said earlier, have you
considered aggregating the User class into the RegisterForm and
LogonForm classes? If required, they could implement the same interface.
I don't really know the design of your system, or how you want it to
work, but for me it would be natural for the User class to be seperate
from the Form classes. Maybe in the constructor of the Form classes, you
can pass a user as a parameter. User can be a property of the forms (ie.
for works with user object).
What are your thoughts?
-Raymond Barlow
Alen Ribic wrote:
Ok I'm back again on this one.
Lets try this again.
My objective:
Using Struts, I will need to create form bean for each Struts form.
So, for example, I will create RegisterForm and LogonForm classes.
As you can se now, these two classes will have similarities in their
getter/setter methods.
Hence I would like to Create a single User class that all these similar form
beans can inherit.
public class RegisterForm extends User {
// inherits necessary setters/getters from User class
public ... validate(...) { // override superclasses version
}
}
public class LogonForm extends User {
// inherits necessary setters/getters from User class
public ... validate(...) { // override superclasses version
}
}
Now I want my form beans also to inherit ValidatorForm class.
So, I add extends on User class as follows: (don't really think this one is
cool, but anyway, it works :) )
public class User extends ValidatorForm {
// setter/getter properties
}
As far as Struts side of things, this seems to be working fine so far.
Only reason I make use of form classes here that inherit my User class is
because of validation requirements specific to each individual form. (needed
in my Struts config) Now there is no way I'm rewriting my User specific
setter/getter properties for each of my forms, e.g. RegisterForm, LogonForm.
Both of these form beans will contain common setter/getter properties which
need to map to the same table called User.
Again, if I need to specify for each form bean (RegisterForm, LogonForm) a
separate class descriptor with it's own, SAME, fields, it would just suck a
bit.
Hope this time I come roght. :)
I really appreciate your help.
--Alen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent. How to?
Ok I'm back again on this one.
Lets try this again.
My objective:
Using Struts, I will need to create form bean for each Struts form.
So, for example, I will create RegisterForm and LogonForm classes.
As you can se now, these two classes will have similarities in their
getter/setter methods.
Hence I would like to Create a single User class that all these similar form
beans can inherit.
public class RegisterForm extends User {
// inherits necessary setters/getters from User class
public ... validate(...) { // override superclasses version
}
}
public class LogonForm extends User {
// inherits necessary setters/getters from User class
public ... validate(...) { // override superclasses version
}
}
Now I want my form beans also to inherit ValidatorForm class.
So, I add extends on User class as follows: (don't really think this one is
cool, but anyway, it works :) )
public class User extends ValidatorForm {
// setter/getter properties
}
As far as Struts side of things, this seems to be working fine so far.
Only reason I make use of form classes here that inherit my User class is
because of validation requirements specific to each individual form. (needed
in my Struts config) Now there is no way I'm rewriting my User specific
setter/getter properties for each of my forms, e.g. RegisterForm, LogonForm.
Both of these form beans will contain common setter/getter properties which
need to map to the same table called User.
Again, if I need to specify for each form bean (RegisterForm, LogonForm) a
separate class descriptor with it's own, SAME, fields, it would just suck a
bit.
Hope this time I come roght. :)
I really appreciate your help.
--Alen
- Original Message -
From: "Thomas Mahler" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, June 03, 2003 11:43 AM
Subject: Re: Extent. How to?
> Hi again Alen.
>
> I think you should define the extent the other way round.
> That is: RegisterForm is the abstract base class and User is the
> concrete class defining all the persistent attributes.
>
>
>
>
>
>class="za.co.alen.jfaq.User"
> table="User"
> >
>
> ...
>
>
> cheers,
> Thomas
>
> Alen Ribic wrote:
> > Thanks Raymond for your reply.
> >
> > This is the thing. I am very lost.
> > The User class descriptor in repository contains all my filed mappings
to my
> > User table in db.
> > Now za.co.alen.struts.RegisterForm class mapping is a very good
question.
> > What would the za.co.alen.struts.RegisterForm class mapping contain? I
don't
> > need any RegisterForm class specific fields at all.
> > I just need to indicate to OJB that it needs to something like cast
> > RegisterForm instance to User and hence would need to map that to User
class
> > / table mapping. (Remember that the instance I get is of
> > za.co.alen.struts.RegisterForm)
> > RegisterForm class does not have any real meaning for persistence
besides
> > the inherited fields from User bean.
> > It basically just contains overridden validate(...) method used for
> > server-side validation in my struts components.
> >
> > I hope this is making sense. :-)
> >
> > --Alen
> >
> >
> >
> > - Original Message -
> > From: "Raymond Barlow" <[EMAIL PROTECTED]>
> > To: "OJB Users List" <[EMAIL PROTECTED]>
> > Sent: Tuesday, June 03, 2003 10:45 AM
> > Subject: Re: Extent. How to?
> >
> >
> >
> >>Hi Alen
> >>
> >>I hate to ask the obvious, but you never know :)
> >>Have you created a mapping for za.co.alen.struts.RegisterForm in your
> >>repository_user.xml file??
> >>
> >>Regards,
> >>Raymond Barlow
> >>
> >>Alen Ribic wrote:
> >>
> >>
> >>>Hi again
> >>>
> >>>I have sent an email already and got a good reply, but now I have an
> >
> > issue
> >
> >>>with mapping side.
> >>>
> >>>I have got classes as follows:
> >>>
> >>>// JavaBean
> >>>public class User extends ValidatorForm {}
> >>>
> >>>// Struts form bean
> >>>public class RegisterForm extends User {}
> >>>
> >>>Now I just need OJB to recognize RegisteForm class as a User.
> >>>
> >>>usr = request.getAttribute("registerForm"); // returns RegisteForm
> >
> > instance
> >
> >>>broker.store(usr);
> >>>
> >>>So now, OJB on store(...) should lo
Re: Extent. How to?
Hi again Alen.
I think you should define the extent the other way round.
That is: RegisterForm is the abstract base class and User is the
concrete class defining all the persistent attributes.
...
cheers,
Thomas
Alen Ribic wrote:
Thanks Raymond for your reply.
This is the thing. I am very lost.
The User class descriptor in repository contains all my filed mappings to my
User table in db.
Now za.co.alen.struts.RegisterForm class mapping is a very good question.
What would the za.co.alen.struts.RegisterForm class mapping contain? I don't
need any RegisterForm class specific fields at all.
I just need to indicate to OJB that it needs to something like cast
RegisterForm instance to User and hence would need to map that to User class
/ table mapping. (Remember that the instance I get is of
za.co.alen.struts.RegisterForm)
RegisterForm class does not have any real meaning for persistence besides
the inherited fields from User bean.
It basically just contains overridden validate(...) method used for
server-side validation in my struts components.
I hope this is making sense. :-)
--Alen
- Original Message -
From: "Raymond Barlow" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, June 03, 2003 10:45 AM
Subject: Re: Extent. How to?
Hi Alen
I hate to ask the obvious, but you never know :)
Have you created a mapping for za.co.alen.struts.RegisterForm in your
repository_user.xml file??
Regards,
Raymond Barlow
Alen Ribic wrote:
Hi again
I have sent an email already and got a good reply, but now I have an
issue
with mapping side.
I have got classes as follows:
// JavaBean
public class User extends ValidatorForm {}
// Struts form bean
public class RegisterForm extends User {}
Now I just need OJB to recognize RegisteForm class as a User.
usr = request.getAttribute("registerForm"); // returns RegisteForm
instance
broker.store(usr);
So now, OJB on store(...) should look at mapping for User class to User
table.
...
I presume that now I need a for the RegisterForm
class.
Is this correct?
I looked at the Article example but I just can't get my one to work.
My app still says that OJB cannot recognize RegisterForm class in
repository.
What am I doing wrong and how can I go about doing this correctly.
Thanks
--Alen
-
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: Extent. How to?
thanks again.
I'll look into this a bit more from app design point of view.
--Alen
- Original Message -
From: "Raymond Barlow" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, June 03, 2003 11:28 AM
Subject: Re: Extent. How to?
> Hi Alen,
>
> I'm fairly new to OJB, but I'm pretty sure that you would have to define
> a class-descriptor for the RegisterForm class. Just try this for now to
> see if it fixes your problem: copy the entire User class descriptor into
> a new RegisterForm class descriptor and just change the relevant bits
> (ie. class="za.co.alen.struts.RegisterForm").
>
> It is a pain, but I think OJB needs to know how to map each extent class
> individually. There has been some postings about using "this" to extend
> mappings, but I've not been able to get this to work successfully.
>
> Just thinking about your problem a bit futher, how is OJB to
> differentiate between a User class and a RegisterForm class when
> searching for a class? ie. If RegisterForm is the same table and
> persistent fields as User, then how can OJB tell if it should be giving
> you a User class or a RegisterForm class? Maybe an alternative for you
> is to have RegisterForm contain an aggregated User class? This way you
> could search for User, then create your RegisterForm class passing the
> relevant User class. Just some ideas
>
> Regards,
> Raymond Barlow
>
> Alen Ribic wrote:
>
> >Thanks Raymond for your reply.
> >
> >This is the thing. I am very lost.
> >The User class descriptor in repository contains all my filed mappings to
my
> >User table in db.
> >Now za.co.alen.struts.RegisterForm class mapping is a very good question.
> >What would the za.co.alen.struts.RegisterForm class mapping contain? I
don't
> >need any RegisterForm class specific fields at all.
> >I just need to indicate to OJB that it needs to something like cast
> >RegisterForm instance to User and hence would need to map that to User
class
> >/ table mapping. (Remember that the instance I get is of
> >za.co.alen.struts.RegisterForm)
> >RegisterForm class does not have any real meaning for persistence besides
> >the inherited fields from User bean.
> >It basically just contains overridden validate(...) method used for
> >server-side validation in my struts components.
> >
> >I hope this is making sense. :-)
> >
> >--Alen
> >
> >
> >
> >- Original Message -
> >From: "Raymond Barlow" <[EMAIL PROTECTED]>
> >To: "OJB Users List" <[EMAIL PROTECTED]>
> >Sent: Tuesday, June 03, 2003 10:45 AM
> >Subject: Re: Extent. How to?
> >
> >
> >
> >
> >>Hi Alen
> >>
> >>I hate to ask the obvious, but you never know :)
> >>Have you created a mapping for za.co.alen.struts.RegisterForm in your
> >>repository_user.xml file??
> >>
> >>Regards,
> >>Raymond Barlow
> >>
> >>Alen Ribic wrote:
> >>
> >>
> >>
> >>>Hi again
> >>>
> >>>I have sent an email already and got a good reply, but now I have an
> >>>
> >>>
> >issue
> >
> >
> >>>with mapping side.
> >>>
> >>>I have got classes as follows:
> >>>
> >>>// JavaBean
> >>>public class User extends ValidatorForm {}
> >>>
> >>>// Struts form bean
> >>>public class RegisterForm extends User {}
> >>>
> >>>Now I just need OJB to recognize RegisteForm class as a User.
> >>>
> >>>usr = request.getAttribute("registerForm"); // returns RegisteForm
> >>>
> >>>
> >instance
> >
> >
> >>>broker.store(usr);
> >>>
> >>>So now, OJB on store(...) should look at mapping for User class to User
> >>>table.
> >>>
> >>> >>> class="za.co.alen.jfaq.User"
> >>> table="User"
> >>> >
> >>>
> >>>
> >>> ...
> >>>
> >>>
> >>>I presume that now I need a for the RegisterForm
> >>>
> >>>
> >class.
> >
> >
> >>>Is this correct?
> >>>I looked at the Article example but I just can't get my one to work.
> >>>
> >>>My app still says that OJB cannot recognize RegisterForm class in
> >>>repository.
> >>>
> >>>What am I doing wrong and how can I go about doing this correctly.
> >>>
> >>>Thanks
> >>>
> >>>--Alen
> >>>
> >>>
> >>>
> >>>-
> >>>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]
> >
> >
> >
> >
>
> --
> Regards,
> Raymond Barlow
>
>
>
> -
> 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: Extent. How to?
Hi Alen,
I'm fairly new to OJB, but I'm pretty sure that you would have to define
a class-descriptor for the RegisterForm class. Just try this for now to
see if it fixes your problem: copy the entire User class descriptor into
a new RegisterForm class descriptor and just change the relevant bits
(ie. class="za.co.alen.struts.RegisterForm").
It is a pain, but I think OJB needs to know how to map each extent class
individually. There has been some postings about using "this" to extend
mappings, but I've not been able to get this to work successfully.
Just thinking about your problem a bit futher, how is OJB to
differentiate between a User class and a RegisterForm class when
searching for a class? ie. If RegisterForm is the same table and
persistent fields as User, then how can OJB tell if it should be giving
you a User class or a RegisterForm class? Maybe an alternative for you
is to have RegisterForm contain an aggregated User class? This way you
could search for User, then create your RegisterForm class passing the
relevant User class. Just some ideas
Regards,
Raymond Barlow
Alen Ribic wrote:
Thanks Raymond for your reply.
This is the thing. I am very lost.
The User class descriptor in repository contains all my filed mappings to my
User table in db.
Now za.co.alen.struts.RegisterForm class mapping is a very good question.
What would the za.co.alen.struts.RegisterForm class mapping contain? I don't
need any RegisterForm class specific fields at all.
I just need to indicate to OJB that it needs to something like cast
RegisterForm instance to User and hence would need to map that to User class
/ table mapping. (Remember that the instance I get is of
za.co.alen.struts.RegisterForm)
RegisterForm class does not have any real meaning for persistence besides
the inherited fields from User bean.
It basically just contains overridden validate(...) method used for
server-side validation in my struts components.
I hope this is making sense. :-)
--Alen
- Original Message -
From: "Raymond Barlow" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, June 03, 2003 10:45 AM
Subject: Re: Extent. How to?
Hi Alen
I hate to ask the obvious, but you never know :)
Have you created a mapping for za.co.alen.struts.RegisterForm in your
repository_user.xml file??
Regards,
Raymond Barlow
Alen Ribic wrote:
Hi again
I have sent an email already and got a good reply, but now I have an
issue
with mapping side.
I have got classes as follows:
// JavaBean
public class User extends ValidatorForm {}
// Struts form bean
public class RegisterForm extends User {}
Now I just need OJB to recognize RegisteForm class as a User.
usr = request.getAttribute("registerForm"); // returns RegisteForm
instance
broker.store(usr);
So now, OJB on store(...) should look at mapping for User class to User
table.
...
I presume that now I need a for the RegisterForm
class.
Is this correct?
I looked at the Article example but I just can't get my one to work.
My app still says that OJB cannot recognize RegisterForm class in
repository.
What am I doing wrong and how can I go about doing this correctly.
Thanks
--Alen
-
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]
--
Regards,
Raymond Barlow
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent. How to?
Thanks Raymond for your reply.
This is the thing. I am very lost.
The User class descriptor in repository contains all my filed mappings to my
User table in db.
Now za.co.alen.struts.RegisterForm class mapping is a very good question.
What would the za.co.alen.struts.RegisterForm class mapping contain? I don't
need any RegisterForm class specific fields at all.
I just need to indicate to OJB that it needs to something like cast
RegisterForm instance to User and hence would need to map that to User class
/ table mapping. (Remember that the instance I get is of
za.co.alen.struts.RegisterForm)
RegisterForm class does not have any real meaning for persistence besides
the inherited fields from User bean.
It basically just contains overridden validate(...) method used for
server-side validation in my struts components.
I hope this is making sense. :-)
--Alen
- Original Message -
From: "Raymond Barlow" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, June 03, 2003 10:45 AM
Subject: Re: Extent. How to?
> Hi Alen
>
> I hate to ask the obvious, but you never know :)
> Have you created a mapping for za.co.alen.struts.RegisterForm in your
> repository_user.xml file??
>
> Regards,
> Raymond Barlow
>
> Alen Ribic wrote:
>
> >Hi again
> >
> >I have sent an email already and got a good reply, but now I have an
issue
> >with mapping side.
> >
> >I have got classes as follows:
> >
> >// JavaBean
> >public class User extends ValidatorForm {}
> >
> >// Struts form bean
> >public class RegisterForm extends User {}
> >
> >Now I just need OJB to recognize RegisteForm class as a User.
> >
> >usr = request.getAttribute("registerForm"); // returns RegisteForm
instance
> >broker.store(usr);
> >
> >So now, OJB on store(...) should look at mapping for User class to User
> >table.
> >
> > > class="za.co.alen.jfaq.User"
> > table="User"
> > >
> >
> >
> > ...
> >
> >
> >I presume that now I need a for the RegisterForm
class.
> >Is this correct?
> >I looked at the Article example but I just can't get my one to work.
> >
> >My app still says that OJB cannot recognize RegisterForm class in
> >repository.
> >
> >What am I doing wrong and how can I go about doing this correctly.
> >
> >Thanks
> >
> >--Alen
> >
> >
> >
> >-
> >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: Extent. How to?
Sorry, just reread your email.
Yes, you do need to define a mapping ( a class-descriptor) for the
RegisterForm class.
Regrads,
Raymond Barlow
Alen Ribic wrote:
Hi again
I have sent an email already and got a good reply, but now I have an issue
with mapping side.
I have got classes as follows:
// JavaBean
public class User extends ValidatorForm {}
// Struts form bean
public class RegisterForm extends User {}
Now I just need OJB to recognize RegisteForm class as a User.
usr = request.getAttribute("registerForm"); // returns RegisteForm instance
broker.store(usr);
So now, OJB on store(...) should look at mapping for User class to User
table.
...
I presume that now I need a for the RegisterForm class.
Is this correct?
I looked at the Article example but I just can't get my one to work.
My app still says that OJB cannot recognize RegisterForm class in
repository.
What am I doing wrong and how can I go about doing this correctly.
Thanks
--Alen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Regards,
Raymond Barlow
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Extent. How to?
Hi Alen
I hate to ask the obvious, but you never know :)
Have you created a mapping for za.co.alen.struts.RegisterForm in your
repository_user.xml file??
Regards,
Raymond Barlow
Alen Ribic wrote:
Hi again
I have sent an email already and got a good reply, but now I have an issue
with mapping side.
I have got classes as follows:
// JavaBean
public class User extends ValidatorForm {}
// Struts form bean
public class RegisterForm extends User {}
Now I just need OJB to recognize RegisteForm class as a User.
usr = request.getAttribute("registerForm"); // returns RegisteForm instance
broker.store(usr);
So now, OJB on store(...) should look at mapping for User class to User
table.
...
I presume that now I need a for the RegisterForm class.
Is this correct?
I looked at the Article example but I just can't get my one to work.
My app still says that OJB cannot recognize RegisterForm class in
repository.
What am I doing wrong and how can I go about doing this correctly.
Thanks
--Alen
-
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]
Extent. How to?
Hi again
I have sent an email already and got a good reply, but now I have an issue
with mapping side.
I have got classes as follows:
// JavaBean
public class User extends ValidatorForm {}
// Struts form bean
public class RegisterForm extends User {}
Now I just need OJB to recognize RegisteForm class as a User.
usr = request.getAttribute("registerForm"); // returns RegisteForm instance
broker.store(usr);
So now, OJB on store(...) should look at mapping for User class to User
table.
...
I presume that now I need a for the RegisterForm class.
Is this correct?
I looked at the Article example but I just can't get my one to work.
My app still says that OJB cannot recognize RegisterForm class in
repository.
What am I doing wrong and how can I go about doing this correctly.
Thanks
--Alen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
