objectbridge-jdo-dev Mailing List for ObJectRelationalBridge (Page 5)
Brought to you by:
thma
Menu
▾
▴
objectbridge-jdo-dev — OJB JDO developer list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(32) |
Feb
(2) |
Mar
(13) |
Apr
(25) |
May
(104) |
Jun
(23) |
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <tr...@th...> - 2002-05-23 16:15:12
|
Well the extenstion tag is part of the jdo spec and is for vendor specific information. 18.5 ELEMENT extension This element specifies JDO vendor extensions. The vendor-name attribute is required. The vendor name "JDORI" is reserved for use by the JDO reference implementation. The key and value attributes are optional, and have vendor-specific meanings. They may be ignored by any JDO implementation. So my thoughts are that people that want to use JDO, can use the jdo file, and the JDO implementation can just setup the ojb metadata classes using the jdo information. This would be in place of repository_user.xml, probably not the repository.xml that holds the database information. Travis ---- Original Message ---- From: Mahler Thomas <tho...@it...> Sent: 2002-05-23 To: "'tr...@th...'" <tr...@th...>, obj...@so... Subject: AW: [Objectbridge-jdo-dev] jdo extension Hi Travis, I don't think that its a good idea to replace the repository.xml by a .jdo file. The JDO spec does not provide any O/R specifics like foreign-keys or jdbc-types. But these information are needed by OJB! My suggestion: The OJB DescriptorRepository (populated from the repository.xml) does contain *all* OJB meta-data. We currently use this repository for all OJB runtime metadata operations and also for generation of DDL, Java code for persistent class and also for generation of repository.xml files. If we need a *.jdo file to be JDO compliant we should generate it from the OJB DescriptorRepository! This is rather simple, fits to the existiting OJB metadata architecture and it will allow to write 100% spec conformant *.jdo files (as they won't need to contain vendor specifics) cheers, Thomas > > > Just thinking of how to do table mapping in the jdo files and > here's my thoughts from sample app: > > <jdo> > <package name="test.ojb.tutorial3a"> > <class name="Product" identity-type="application"> > <extension vendor-name="ojb" table-name="Product"/> > <field name="id" primary-key="true"> > <extension vendor-name="ojb" column-name="id"/> > </field> > <field name="name"> > <extension vendor-name="ojb" column-name="name"/> > </field> > <field name="price"> > <extension vendor-name="ojb" column-name="price"/> > </field> > <field name="stock"> > <extension vendor-name="ojb" column-name="stock"/> > </field> > </class> > </package> > </jdo> > > > I don't think we'll need the jdbc datatypes anymore do we? feedback? > > Travis > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > |
|
From: Mahler T. <tho...@it...> - 2002-05-23 08:50:02
|
Hi Travis, I don't think that its a good idea to replace the repository.xml by a .jdo file. The JDO spec does not provide any O/R specifics like foreign-keys or jdbc-types. But these information are needed by OJB! My suggestion: The OJB DescriptorRepository (populated from the repository.xml) does contain *all* OJB meta-data. We currently use this repository for all OJB runtime metadata operations and also for generation of DDL, Java code for persistent class and also for generation of repository.xml files. If we need a *.jdo file to be JDO compliant we should generate it from the OJB DescriptorRepository! This is rather simple, fits to the existiting OJB metadata architecture and it will allow to write 100% spec conformant *.jdo files (as they won't need to contain vendor specifics) cheers, Thomas > > > Just thinking of how to do table mapping in the jdo files and > here's my thoughts from sample app: > > <jdo> > <package name="test.ojb.tutorial3a"> > <class name="Product" identity-type="application"> > <extension vendor-name="ojb" table-name="Product"/> > <field name="id" primary-key="true"> > <extension vendor-name="ojb" column-name="id"/> > </field> > <field name="name"> > <extension vendor-name="ojb" column-name="name"/> > </field> > <field name="price"> > <extension vendor-name="ojb" column-name="price"/> > </field> > <field name="stock"> > <extension vendor-name="ojb" column-name="stock"/> > </field> > </class> > </package> > </jdo> > > > I don't think we'll need the jdbc datatypes anymore do we? feedback? > > Travis > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > |
|
From: Mahler T. <tho...@it...> - 2002-05-23 07:53:18
|
Hi Sebastian, <snip intro> > > in fact I'm really interested in helping on a jdo open-source > implementation > and I've already done some work at home. Now, I've found ojb > and I'm trying > to investigate, how easy it would be, to use it as the > storage backend. > However, this is somewhat difficult, as the documentation > about the internal > things (not how to use it from a user perspective) is not > always optimal --- > which I probably wouldn't do better on my own projects... :( > If you have a short look at Travis' implementation you will see that it does not make use of any internal OJB structures. It is a simple PersistenceBroker API client application. The same holds true for the OJB-ODMG implementation: it is just a client using the PersistenceBroker Interface. I explained this layered approch in my jdo-psoposal: http://objectbridge.sourceforge.net/jdo/jdo-proposal.html But I agree to you: the documentation of OJB internals is far from being complete. It will be a good idea to improve it! > So, I'll certainly stay on this list and help if I can... fine, all help is appreciated. ciao, Thomas > ciao Sebastian > > > -- > Sebastian Kanthak | seb...@mu... > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > |
|
From: <tr...@th...> - 2002-05-22 22:43:05
|
Just thinking of how to do table mapping in the jdo files and here's my thoughts from sample app:
<jdo>
<package name="test.ojb.tutorial3a">
<class name="Product" identity-type="application">
<extension vendor-name="ojb" table-name="Product"/>
<field name="id" primary-key="true">
<extension vendor-name="ojb" column-name="id"/>
</field>
<field name="name">
<extension vendor-name="ojb" column-name="name"/>
</field>
<field name="price">
<extension vendor-name="ojb" column-name="price"/>
</field>
<field name="stock">
<extension vendor-name="ojb" column-name="stock"/>
</field>
</class>
</package>
</jdo>
I don't think we'll need the jdbc datatypes anymore do we? feedback?
Travis
|
|
From: <tr...@th...> - 2002-05-22 21:45:55
|
sounds like you may not have downloaded the jdori.jar. Travis ---- Original Message ---- From: David Forslund <dw...@la...> Sent: 2002-05-22 To: Thomas Mahler <tho...@ho...>, tr...@th... Subject: Re: [OJB-developers] replace javax.jdo source in current tree with latest jar When I do the run_jdo_example, I get a failure with NoClassDefFoundErr;r: com/sun/jdori/enhancer/Main. Looks like something is missing here. How does one get the JDO example to work "out of the box"? Dave At 09:11 PM 5/22/2002 +0200, Thomas Mahler wrote: >Hi Travis, > >I just checked out your latest stuff from CVS. >Wow! >We have a working JDO sample application! That's really a good beginning. > > >It all runs out of the box ! cool! > >Thank you for your efforts! > >Of course now all the "real" work begins: implementing the instance live >cycle management, implementing real JDOQL query etc., etc. > >I hope, that now that you contributed a working base, more and more >developers start working on OJB-JDO. >Everyone is invited! > > >One minor issue: you included the jdori.jar into the OJB lib directory. >As far as I can see you are using it only for the enhancement, right? >Is it allowed to ship this jar file with OJB? >If there are any possible legal issues, we should use a different (i.e. a >selfimplemented) enhancer. > >thanks again, > >Thomas > > >tr...@th... wrote: > >>Any objections to this? The source in the ojb tree isn't the latest jdo >>spec. I would like to remove the jdo package and replace with the >>jdo.jar in the lib directory. There is a different structure and may >>cause some issues if anybody is using it elsewhere. >>Travis >>_______________________________________________________________ >>Don't miss the 2002 Sprint PCS Application Developer's Conference >>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm >>_______________________________________________ >>Objectbridge-developers mailing list >>Obj...@li... >>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers >> > > > >_______________________________________________________________ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >_______________________________________________ >Objectbridge-developers mailing list >Obj...@li... >https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: Sebastian K. <seb...@mu...> - 2002-05-22 21:27:35
|
Hi Travis, On Friday 17 May 2002 16:08, you wrote: > I just really want to be able to use JDO right now and at the same time get > all the benefits of using OJB. If you or others are thinking hte same way, > then everyone who is interested should help out with this project so we can > get a real implementation going. It sounds like you know the JDO spec like > the back of your hand and any input you have on implementing it would be > greatly appreciated. in fact I'm really interested in helping on a jdo open-source implementation and I've already done some work at home. Now, I've found ojb and I'm trying to investigate, how easy it would be, to use it as the storage backend. However, this is somewhat difficult, as the documentation about the internal things (not how to use it from a user perspective) is not always optimal --- which I probably wouldn't do better on my own projects... :( So, I'll certainly stay on this list and help if I can... ciao Sebastian -- Sebastian Kanthak | seb...@mu... |
|
From: David F. <dw...@la...> - 2002-05-22 20:27:02
|
When I do the run_jdo_example, I get a failure with NoClassDefFoundErr;r: com/sun/jdori/enhancer/Main. Looks like something is missing here. How does one get the JDO example to work "out of the box"? Dave At 09:11 PM 5/22/2002 +0200, Thomas Mahler wrote: >Hi Travis, > >I just checked out your latest stuff from CVS. >Wow! >We have a working JDO sample application! That's really a good beginning. > > >It all runs out of the box ! cool! > >Thank you for your efforts! > >Of course now all the "real" work begins: implementing the instance live >cycle management, implementing real JDOQL query etc., etc. > >I hope, that now that you contributed a working base, more and more >developers start working on OJB-JDO. >Everyone is invited! > > >One minor issue: you included the jdori.jar into the OJB lib directory. >As far as I can see you are using it only for the enhancement, right? >Is it allowed to ship this jar file with OJB? >If there are any possible legal issues, we should use a different (i.e. a >selfimplemented) enhancer. > >thanks again, > >Thomas > > >tr...@th... wrote: > >>Any objections to this? The source in the ojb tree isn't the latest jdo >>spec. I would like to remove the jdo package and replace with the >>jdo.jar in the lib directory. There is a different structure and may >>cause some issues if anybody is using it elsewhere. >>Travis >>_______________________________________________________________ >>Don't miss the 2002 Sprint PCS Application Developer's Conference >>August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm >>_______________________________________________ >>Objectbridge-developers mailing list >>Obj...@li... >>https://lists.sourceforge.net/lists/listinfo/objectbridge-developers >> > > > >_______________________________________________________________ > >Don't miss the 2002 Sprint PCS Application Developer's Conference >August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > >_______________________________________________ >Objectbridge-developers mailing list >Obj...@li... >https://lists.sourceforge.net/lists/listinfo/objectbridge-developers |
|
From: <tr...@th...> - 2002-05-22 20:13:12
|
We must be able to at least use the jdo.jar ? Or how else could anybody (commercial implementations) use jdo? Travis ---- Original Message ---- From: Florian Bruckner <bf...@fl...> Sent: 2002-05-22 To: Thomas Mahler <tho...@ho...>, tr...@th... Subject: [Objectbridge-jdo-dev] RE: [OJB-developers] replace javax.jdo source in current tree with latest jar Hi, > One minor issue: you included the jdori.jar into the OJB lib directory. > As far as I can see you are using it only for the enhancement, right? > Is it allowed to ship this jar file with OJB? > If there are any possible legal issues, we should use a different (i.e. > a selfimplemented) enhancer. > > thanks again, > > Thomas just checked the license of the two files in question. IANAL, but I think we'll have to remove them to avoid licensing issues. jdo.jar and jdori.jar are part of the reference implementation of JDO from Sun, and that is licensed unter the sun community source license. The paragraph in question says: " a) Research Use License: (i) use, reproduce and modify the Original Code, Upgraded Code and Specifications to create Modifications and Reformatted Specifications for Research Use by You, (ii) publish and display Original Code, Upgraded Code and Specifications with, or as part of Modifications, as permitted under Section 3.1 b) below, (iii) reproduce and distribute copies of Original Code and Upgraded Code to Licensees and students for Research Use by You, (iv) compile, reproduce and distribute Original Code and Upgraded Code in Executable form, and Reformatted Specifications to anyone for Research Use by You. " My understanding of this paragraph is, that we'd only be able the JDO part of OJB under these conditions and only for research. This implies that we'll not be able to release a "production quality" version of OJB-JDO. What we jave to go for is a "clean-room" implementation, the requirements for this are stipulated in the license of the JDO specification: " Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Sun's intellectual property rights that are essential to practice the Specification, to internally practice the Specification for the purpose of designing and developing your Java applets and applications intended to run on the Java platform or creating a clean room implementation of the Specification that: (i) includes a complete implementation of the current version of the Specification, without subsetting or supersetting; (ii) implements all of the interfaces and functionality of the Specification without subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by the Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all of the interfaces and functionality of such optional components, without subsetting or supersetting; (v) does not add any additional packages, classes or interfaces to the "java.*" or "javax.*" packages or subpackages or other packages defined by the Specification; (vi) satisfies all testing requirements available from Sun relating to the most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; (vii) does not derive from any Sun source code or binary code materials; and (viii) does not include any Sun source code or binary code materials without an appropriate and separate license from Sun. The Specification contains the proprietary information of Sun and may only be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from Sun if you fail to comply with any provision of this license. Upon termination or expiration of this license, you must cease use of or destroy the Specification. " jdo.jar is also part of the specification, but paragraph viii contains a clause that this .jar mustn't be used by a clean-room implementation as well (and that is our goal, isn't it?) I don't want to spread any FUD, but we should check these things before proceeding. I'd also think that we should contact sombody of jakarta who is familiar with licensing issues. best regards, Florian _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Objectbridge-jdo-dev mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev |
|
From: Florian B. <bf...@fl...> - 2002-05-22 19:50:04
|
Hi, > One minor issue: you included the jdori.jar into the OJB lib directory. > As far as I can see you are using it only for the enhancement, right? > Is it allowed to ship this jar file with OJB? > If there are any possible legal issues, we should use a different (i.e. > a selfimplemented) enhancer. > > thanks again, > > Thomas just checked the license of the two files in question. IANAL, but I think we'll have to remove them to avoid licensing issues. jdo.jar and jdori.jar are part of the reference implementation of JDO from Sun, and that is licensed unter the sun community source license. The paragraph in question says: " a) Research Use License: (i) use, reproduce and modify the Original Code, Upgraded Code and Specifications to create Modifications and Reformatted Specifications for Research Use by You, (ii) publish and display Original Code, Upgraded Code and Specifications with, or as part of Modifications, as permitted under Section 3.1 b) below, (iii) reproduce and distribute copies of Original Code and Upgraded Code to Licensees and students for Research Use by You, (iv) compile, reproduce and distribute Original Code and Upgraded Code in Executable form, and Reformatted Specifications to anyone for Research Use by You. " My understanding of this paragraph is, that we'd only be able the JDO part of OJB under these conditions and only for research. This implies that we'll not be able to release a "production quality" version of OJB-JDO. What we jave to go for is a "clean-room" implementation, the requirements for this are stipulated in the license of the JDO specification: " Sun hereby grants you a fully-paid, non-exclusive, non-transferable, worldwide, limited license (without the right to sublicense), under Sun's intellectual property rights that are essential to practice the Specification, to internally practice the Specification for the purpose of designing and developing your Java applets and applications intended to run on the Java platform or creating a clean room implementation of the Specification that: (i) includes a complete implementation of the current version of the Specification, without subsetting or supersetting; (ii) implements all of the interfaces and functionality of the Specification without subsetting or supersetting; (iii) includes a complete implementation of any optional components (as defined by the Specification) which you choose to implement, without subsetting or supersetting; (iv) implements all of the interfaces and functionality of such optional components, without subsetting or supersetting; (v) does not add any additional packages, classes or interfaces to the "java.*" or "javax.*" packages or subpackages or other packages defined by the Specification; (vi) satisfies all testing requirements available from Sun relating to the most recently published version of the Specification six (6) months prior to any release of the clean room implementation or upgrade thereto; (vii) does not derive from any Sun source code or binary code materials; and (viii) does not include any Sun source code or binary code materials without an appropriate and separate license from Sun. The Specification contains the proprietary information of Sun and may only be used in accordance with the license terms set forth herein. This license will terminate immediately without notice from Sun if you fail to comply with any provision of this license. Upon termination or expiration of this license, you must cease use of or destroy the Specification. " jdo.jar is also part of the specification, but paragraph viii contains a clause that this .jar mustn't be used by a clean-room implementation as well (and that is our goal, isn't it?) I don't want to spread any FUD, but we should check these things before proceeding. I'd also think that we should contact sombody of jakarta who is familiar with licensing issues. best regards, Florian |
|
From: <tr...@th...> - 2002-05-22 19:46:24
|
Thanks. ;-) Ya, I am thinking the following needs to be done sooner rather than later: 1. Complete PersistenceManager and PersistenceManagerFactory entirely. 2. Use .jdo files instead of repository.xml. 3. Complete JDOHelper. 4. JDOQL In no particular order... As for the jdori.jar, yes, it's just for enhancement and I was wondering the same thing. Travis ---- Original Message ---- From: Thomas Mahler <tho...@ho...> Sent: 2002-05-22 To: tr...@th... Subject: Re: [OJB-developers] replace javax.jdo source in current tree with latest jar Hi Travis, I just checked out your latest stuff from CVS. Wow! We have a working JDO sample application! That's really a good beginning. It all runs out of the box ! cool! Thank you for your efforts! Of course now all the "real" work begins: implementing the instance live cycle management, implementing real JDOQL query etc., etc. I hope, that now that you contributed a working base, more and more developers start working on OJB-JDO. Everyone is invited! One minor issue: you included the jdori.jar into the OJB lib directory. As far as I can see you are using it only for the enhancement, right? Is it allowed to ship this jar file with OJB? If there are any possible legal issues, we should use a different (i.e. a selfimplemented) enhancer. thanks again, Thomas tr...@th... wrote: > Any objections to this? The source in the ojb tree isn't the latest jdo spec. I would like to remove the jdo package and replace with the jdo.jar in the lib directory. There is a different structure and may cause some issues if anybody is using it elsewhere. > > Travis > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: Thomas M. <tho...@ho...> - 2002-05-22 19:11:44
|
Hi Travis, I just checked out your latest stuff from CVS. Wow! We have a working JDO sample application! That's really a good beginning. It all runs out of the box ! cool! Thank you for your efforts! Of course now all the "real" work begins: implementing the instance live cycle management, implementing real JDOQL query etc., etc. I hope, that now that you contributed a working base, more and more developers start working on OJB-JDO. Everyone is invited! One minor issue: you included the jdori.jar into the OJB lib directory. As far as I can see you are using it only for the enhancement, right? Is it allowed to ship this jar file with OJB? If there are any possible legal issues, we should use a different (i.e. a selfimplemented) enhancer. thanks again, Thomas tr...@th... wrote: > Any objections to this? The source in the ojb tree isn't the latest jdo spec. I would like to remove the jdo package and replace with the jdo.jar in the lib directory. There is a different structure and may cause some issues if anybody is using it elsewhere. > > Travis > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Objectbridge-developers mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-developers > > > > |
|
From: Sebastian K. <seb...@mu...> - 2002-05-17 20:43:59
|
Hi, On Friday 17 May 2002 15:01, Jim Hughes wrote: > According to the spec they are required at runtime and enhancement > time. They are needed at enhancement time to (at the very least) > specify which files are persistent. I'm not sure why they're needed at > runtime, but the spec says they are. you are right, they are needed at runtime, too. For example, if the schema-mapping is stored in these files, the jdo-implementation obviously needs it. Even if no vendor-extensions are present, they have to be present to know some settings for persistent fields, for example, whether to store embedded or not, whether a field is transient (not to be confused with the java keyword with the same name), transactional or persistent, of which classes collection members are and so on... ciao Sebastian -- Sebastian Kanthak | seb...@mu... |
|
From: Jim H. <je...@hu...> - 2002-05-17 18:03:02
|
According to the spec they are required at runtime and enhancement time. They are needed at enhancement time to (at the very least) specify which files are persistent. I'm not sure why they're needed at runtime, but the spec says they are. J. On Fri, 2002-05-17 at 09:12, tr...@th... wrote: > Do the .jdo files need to be accessible at runtime or just at enhancement time? Sounds like just at enhancement time and even that's optional (will do default action if no jdo file found). > > Travis > > |
|
From: <tr...@th...> - 2002-05-17 14:18:16
|
Do the .jdo files need to be accessible at runtime or just at enhancement time? Sounds like just at enhancement time and even that's optional (will do default action if no jdo file found). Travis |
|
From: <tr...@th...> - 2002-05-17 14:13:49
|
I think you're right for the most part and I hope that more things will get developed as needed such as the StateManager. I just really want to be able to use JDO right now and at the same time get all the benefits of using OJB. If you or others are thinking hte same way, then everyone who is interested should help out with this project so we can get a real implementation going. It sounds like you know the JDO spec like the back of your hand and any input you have on implementing it would be greatly appreciated. cheers Travis ---- Original Message ---- From: Sebastian Kanthak <seb...@mu...> Sent: 2002-05-17 To: obj...@so... Subject: Re: Re: Re: [Objectbridge-jdo-dev] JDO implementation Hi Travis, On Friday 17 May 2002 03:03, you wrote: > I made a tutorial3a package that has the Product that does NOT implement > PersistenceCapable. Modified build.xml to enhance Product after > compilation. > > And it all works just fine. Nothing broken. well. That's because no state manager has been set and all field accesses are performed directly. However, try the isXXX methods from javax.jdo.JDOHelper. For example JDOHelper.isPersistent(...) will always delegate to the state manager. If no state manager is present (as in your case), this method will always return "false", even if the persistence capable instance is persistent. Same for isDirty(...) and so on. So you have to put in a state manager. If you do this, however, most field accesses (depends on jdoFlags and jdoFieldFlags) are delegated to the state manager. I think another problem occurs with "lazy-materialization". Suppose you have a very large graph of objects. When you load one object via some kind of query, you probably don't want all objects to be loaded at once, but to load them transparently on-demand, when they are accessed. I'm no ojb expert here, but I think, ojb supports this by creating "stub"-objects via the jdk1.3 proxy feature. When these stubs are accessed the first time, they load the "real" object and pass all calls to it in the future. OJB-developers, correct me, I'm a wrong here. While this solutions works and is a nice application of the proxy feature, it has several drawbacks in my opinion. The most important is, that it does only work with interfaces (correct?). Others are use of a jdk1.3 feature and additional unnecessary objects (the stubs) that add another method call. JDO has the possibility for another solution because of its use of an enhancer. Because field accesses are delegated to the state manager (which resembles the proxy object a bit), he can decide, when to load objects from the database. Don't get me wrong. I think, that ojb can be used very well for a jdo implementation, but as jdo has a slightly different approach, it can only be used as a "backend" behind a jdo-layer, that is responsible for the communication database <-> state manager. The communication with the persistent capable objects is the responsibility of the jdo layer and has yet to be developed. ciao Sebastian -- Sebastian Kanthak | seb...@mu... _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: ban...@so... _______________________________________________ Objectbridge-jdo-dev mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev |
|
From: Sebastian K. <seb...@mu...> - 2002-05-17 13:37:09
|
Hi Travis, On Friday 17 May 2002 03:03, you wrote: > I made a tutorial3a package that has the Product that does NOT implement > PersistenceCapable. Modified build.xml to enhance Product after > compilation. > > And it all works just fine. Nothing broken. well. That's because no state manager has been set and all field accesses are performed directly. However, try the isXXX methods from javax.jdo.JDOHelper. For example JDOHelper.isPersistent(...) will always delegate to the state manager. If no state manager is present (as in your case), this method will always return "false", even if the persistence capable instance is persistent. Same for isDirty(...) and so on. So you have to put in a state manager. If you do this, however, most field accesses (depends on jdoFlags and jdoFieldFlags) are delegated to the state manager. I think another problem occurs with "lazy-materialization". Suppose you have a very large graph of objects. When you load one object via some kind of query, you probably don't want all objects to be loaded at once, but to load them transparently on-demand, when they are accessed. I'm no ojb expert here, but I think, ojb supports this by creating "stub"-objects via the jdk1.3 proxy feature. When these stubs are accessed the first time, they load the "real" object and pass all calls to it in the future. OJB-developers, correct me, I'm a wrong here. While this solutions works and is a nice application of the proxy feature, it has several drawbacks in my opinion. The most important is, that it does only work with interfaces (correct?). Others are use of a jdk1.3 feature and additional unnecessary objects (the stubs) that add another method call. JDO has the possibility for another solution because of its use of an enhancer. Because field accesses are delegated to the state manager (which resembles the proxy object a bit), he can decide, when to load objects from the database. Don't get me wrong. I think, that ojb can be used very well for a jdo implementation, but as jdo has a slightly different approach, it can only be used as a "backend" behind a jdo-layer, that is responsible for the communication database <-> state manager. The communication with the persistent capable objects is the responsibility of the jdo layer and has yet to be developed. ciao Sebastian -- Sebastian Kanthak | seb...@mu... |
|
From: Thomas M. <tho...@ho...> - 2002-05-17 10:33:07
|
Hi Travis,
tr...@th... wrote:
> How does OJB handle things like:
>
> public class Person
> {
> String Name;
> Address myAddress;
> }
>
> public class Address
> {
> String street1;
> String street2;
> String city;
> String state;
> String zip;
> }
>
> Would the address instance in a person instance be persistent if you
stored the person instance?
>
Depends! Have a look at tutorial 3 how to define cascading deletes,
updates and inserts. The behaviour can be configured in the repository.
> Or what if that person class looked like this:
>
> public class Person
> {
> String Name;
> java.util.List addresses; // list of address objects
> }
>
> Does ojb have any way of dealing with that?
>
Sure ! Have a look at tuorial 3 to see how to define 1:1, 1:n and m:n
associations.
> Travis Reeder
> Chief Software Architect
> www.ThinkVirtual.com
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We
supply
> the hardware. You get the recognition. Email Us:
ban...@so...
> _______________________________________________
> Objectbridge-jdo-dev mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev
>
>
>
>
|
|
From: <tr...@th...> - 2002-05-17 01:09:13
|
I made a tutorial3a package that has the Product that does NOT implement PersistenceCapable. Modified build.xml to enhance Product after compilation. And it all works just fine. Nothing broken. Travis ---- Original Message ---- From: Sebastian Kanthak <seb...@mu...> Sent: 2002-05-16 To: obj...@so... Subject: Re: Re: [Objectbridge-jdo-dev] JDO implementation Hi Travis, On Wednesday 15 May 2002 19:07, you wrote: > I would like to turn it into a complete JDO implementation and hopefully it > will in time. Any helpers? As for the enhancers, let me put it this way, > it won't break anything. ;-) I don't think, you are right regarding enhancers. Enhanced classes delegate a lot of work to the state manager (for example field access and status interrogation). So if a state manager is not present, it should not work. ciao Sebastian -- Sebastian Kanthak | seb...@mu... _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: ban...@so... _______________________________________________ Objectbridge-jdo-dev mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev |
|
From: Sebastian K. <seb...@mu...> - 2002-05-16 21:48:38
|
Hi Travis, On Wednesday 15 May 2002 19:07, you wrote: > I would like to turn it into a complete JDO implementation and hopefully it > will in time. Any helpers? As for the enhancers, let me put it this way, > it won't break anything. ;-) I don't think, you are right regarding enhancers. Enhanced classes delegate a lot of work to the state manager (for example field access and status interrogation). So if a state manager is not present, it should not work. ciao Sebastian -- Sebastian Kanthak | seb...@mu... |
|
From: Sebastian K. <seb...@mu...> - 2002-05-16 21:46:50
|
Hi Travis, On Thursday 16 May 2002 23:25, tr...@th... wrote: > Should the reference enhancer work for most implementations? a jdo-compliant implementation has to work with classes enhanced by the reference enhancer as well as classes enhanced by enhancers of other jdo-compliant implementations. > Also, when should the enhancement take place? Using the tutorial app as an > example, You have your Product class. Now do you enhance before you can > start using it, or do you enhance at runtime? Seems like it would be a > pain to have to enhance every class every time you make a change? enhancement has to take place, before the classes are used. Normally this means, that you have to do it right after compilation, which can be done via an ant task easily. However, it would be possible, to write a special classloader, that does enhancement "on the fly" when loading the classes. ciao Sebastian -- Sebastian Kanthak | seb...@mu... |
|
From: Jim H. <je...@hu...> - 2002-05-16 21:42:59
|
travis> Should the reference enhancer work for most implementations?
Yes. The spec requires that enhanced classes should be able to dropped
into any compliant jdo impl and work. Theoretically, there is not
reason for any jdo vendor to code an enhancer; they could just license
the ri's enhancer.
travis> Also, when should the enhancement take place?
When you build. IDE's should eventually begin to support it, but for
now this is best done with ant. Some impls include a custom ant task,
but it's doable with plain java classes, as long as the impl exposes the
enhancement classes. Here's an example using the ri:
<target name="enhance" depends="compile">
<java fork="yes" failonerror="yes"
classname="com.sun.jdori.enhancer.Main"
classpathref="classpath">
<arg line="-f -d ${classdir}
${classdir}/com/hughesorama/jdoex/testfixture.jdo ${test.dao.classes}"/>
</java>
</target>
Jim
|
|
From: <tr...@th...> - 2002-05-16 21:31:05
|
Should the reference enhancer work for most implementations? Also, when should the enhancement take place? Using the tutorial app as an example, You have your Product class. Now do you enhance before you can start using it, or do you enhance at runtime? Seems like it would be a pain to have to enhance every class every time you make a change? Travis |
|
From: <tr...@th...> - 2002-05-15 17:12:36
|
You're completely correct. What I have going so far is very minimal, just to get it working and usable. The main point right now is that you can use the JDO api. I would like to turn it into a complete JDO implementation and hopefully it will in time. Any helpers? As for the enhancers, let me put it this way, it won't break anything. ;-) Travis ---- Original Message ---- From: Sebastian Kanthak <seb...@mu...> Sent: 2002-05-15 To: obj...@so... Subject: Re: [Objectbridge-jdo-dev] JDO implementation Hi Travis, On Tuesday 14 May 2002 20:09, tr...@th... wrote: > Please try it and let me know if you have any troubles. thanks. I've taken a look at your source code, but did not have time to try it out. However, I have the following question: It seems to me, that you don't have implemented StateManager for example, so I'm wondering if your implementation is able to work with classes, enhanced by (for example) the reference enhancer? As far as I can see, you are doing more or less an implementation, that replaces the OJB-API (PersistenceBroker and so on) via the JDO-API. However, that's only a small part of JDO. More important in my opinion, is the way PersistenceCapable and StateManager to allow lazy instantiation and all the different life-cycle states. Are you planning to work into this direction or do you merely want OJB with an JDO-like interface? Of course, I'm aware, that your project is at the very beginning, so don't take it as a critic. I'm only interessted in the way you want to go. ciao Sebastian -- Sebastian Kanthak | seb...@mu... _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: ban...@so... _______________________________________________ Objectbridge-jdo-dev mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev |
|
From: Sebastian K. <seb...@mu...> - 2002-05-15 16:02:20
|
Hi Travis, On Tuesday 14 May 2002 20:09, tr...@th... wrote: > Please try it and let me know if you have any troubles. thanks. I've taken a look at your source code, but did not have time to try it out. However, I have the following question: It seems to me, that you don't have implemented StateManager for example, so I'm wondering if your implementation is able to work with classes, enhanced by (for example) the reference enhancer? As far as I can see, you are doing more or less an implementation, that replaces the OJB-API (PersistenceBroker and so on) via the JDO-API. However, that's only a small part of JDO. More important in my opinion, is the way PersistenceCapable and StateManager to allow lazy instantiation and all the different life-cycle states. Are you planning to work into this direction or do you merely want OJB with an JDO-like interface? Of course, I'm aware, that your project is at the very beginning, so don't take it as a critic. I'm only interessted in the way you want to go. ciao Sebastian -- Sebastian Kanthak | seb...@mu... |
|
From: <tr...@th...> - 2002-05-14 18:14:30
|
Ok, so i made some major changes to the JDO implementation at http://johndoe.sourceforge.net. The jdo classes no longer extend OJB classes, they just use them as private members to hide them from users and it also means, that no changes are required anymore to the OJB install. You can leave the properties file and everything alone and this should work fine. Tutorial application is updated as well. Please try it and let me know if you have any troubles. thanks. Travis Reeder |
