objectbridge-jdo-dev Mailing List for ObJectRelationalBridge (Page 3)
Brought to you by:
thma
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-28 17:48:42
|
I've been having this idea running through my head for the past couple weeks so I thought i'd run it by the list. Lets say you wanted to make the database transparent (other than the connection info obviously) so we could have a quasi object store. My thoughts on how to implement speaking from jdo implementation perspective. Basically you have jdo file with persistent fields. If a table not found error occurs on a query, you create the table on the fly. If a column not found error occurs, you compare ResultSet metadata with jdo metadata and create any columns that dont' match. This could be done at load time when jdo file is first read, or on the fly on an as needed basis. The benefit of this is that the jdo file would become a sort of database schema that the programmer wouldn't even think about. And ojb would be very, very easy to install and implement. Thoughts? Travis |
From: Mahler T. <tho...@it...> - 2002-05-28 14:03:33
|
Hi > > At what point should a PersistenceCapable instance get > assigned a StateManager? > tough question! Maybe you'll find something in the JDORI?! Thomas > 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-28 13:59:09
|
Hi again Arvind, =20 -----Urspr=FCngliche Nachricht----- Von: Arvind Gudipati [mailto:Arv...@PA...] Gesendet: Dienstag, 28. Mai 2002 15:36 An: Mahler Thomas Cc: obj...@li... Betreff: RE: [Objectbridge-jdo-dev] (no subject) May i please know what does the next public release (commin in 1 or 2 = weeks) containg latest JDO stuff contain?..though sun's JDO is still a = reference implementation i still like the idea of using JDO to abstract my = persistence layer.=20 Our current stuff is only a prototype. It's not ready for use in = production level environments. It has no JDOQL, no Statemanagement (instance lifecycle), no = transaction management, etc. =20 Just check out the latest stuff from cvs and have a look ! =20 On the side note: =20 Currently Castor gives a good abstraction layer but however i dont like = the fact that it is not JDO complaint yet. =20 Castor has never been designed for compliance to SUN JDO or ODMG. I = don't think that it will ever achieve JDO compliance as it is no longer under active development. =20 cu, =20 Thomas I switched over to OJB for other reasons related to bugs that are too complicated to resolve in castor. Also IMO , OJB is much easier to understand and debug than castor. =20 -----Original Message----- From: Mahler Thomas [mailto:tho...@it...] Sent: Tuesday, May 28, 2002 9:00 AM To: 'obj...@li...' Cc: 'Arv...@PA...' Subject: AW: [Objectbridge-jdo-dev] (no subject) Hi Arvind, =20 There is currently no public release containing a JDO implementation. Currently the JDO implementation can be checkout from our CVS = repository only. =20 The next public release (will come within 1 or 2 weeks) will contain = our latest JDO stuff. The current JDO implementatin is far from being complete. There is currently no schedule or time-line for a complete JDO impl. =20 HTH, =20 Thomas =20 -----Urspr=FCngliche Nachricht----- Von: Arvind Gudipati [mailto:Arv...@PA...] Gesendet: Dienstag, 28. Mai 2002 14:50 An: obj...@li... Betreff: [Objectbridge-jdo-dev] (no subject) Hi,=20 Is there any time-line for completion of JDO proposal for OJB? = Which build contains the current implementation of JDO based OJB? Was = wondering how complete is it? Arvind=20 ************************************************************************= **** ************* This E-mail is from = PANACYA Inc. The E-mail and any files transmitted with it are confidential and = may also be privileged and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized direct or indirect dissemination, distribution or copying of this message and any = attachments is strictly prohibited. If you have received the E-mail in error please notify adm...@pa... or telephone (410) 910-3300. ************************************************************************= **** ************ ************************************************************************= **** ************* This E-mail is from PANACYA Inc. The E-mail and any files transmitted with it are confidential and may also be privileged and = intended solely for the use of the individual or entity to whom they are = addressed. Any unauthorized direct or indirect dissemination, distribution or = copying of this message and any attachments is strictly prohibited. If you have received the E-mail in error please notify adm...@pa... or telephone (410) 910-3300. ************************************************************************= **** ************ |
From: Arvind G. <Arv...@PA...> - 2002-05-28 13:36:19
|
May i please know what does the next public release (commin in 1 or 2 = weeks) containg latest JDO stuff contain?..though sun's JDO is still a = reference implementation i still like the idea of using JDO to abstract my = persistence layer.=20 =20 =20 On the side note: =20 Currently Castor gives a good abstraction layer but however i dont like = the fact that it is not JDO complaint yet. I switched over to OJB for other reasons related to bugs that are too complicated to resolve in castor. = Also IMO , OJB is much easier to understand and debug than castor. =20 -----Original Message----- From: Mahler Thomas [mailto:tho...@it...] Sent: Tuesday, May 28, 2002 9:00 AM To: 'obj...@li...' Cc: 'Arv...@PA...' Subject: AW: [Objectbridge-jdo-dev] (no subject) Hi Arvind, =20 There is currently no public release containing a JDO implementation. Currently the JDO implementation can be checkout from our CVS = repository only. =20 The next public release (will come within 1 or 2 weeks) will contain = our latest JDO stuff. The current JDO implementatin is far from being complete. There is currently no schedule or time-line for a complete JDO impl. =20 HTH, =20 Thomas =20 -----Urspr=FCngliche Nachricht----- Von: Arvind Gudipati [mailto:Arv...@PA...] Gesendet: Dienstag, 28. Mai 2002 14:50 An: obj...@li... Betreff: [Objectbridge-jdo-dev] (no subject) Hi,=20 Is there any time-line for completion of JDO proposal for OJB? = Which build contains the current implementation of JDO based OJB? Was = wondering how complete is it? Arvind=20 ************************************************************************= **** ************* This E-mail is from = PANACYA Inc. The E-mail and any files transmitted with it are confidential and = may also be privileged and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized direct or indirect dissemination, distribution or copying of this message and any = attachments is strictly prohibited. If you have received the E-mail in error please notify adm...@pa... or telephone (410) 910-3300. ************************************************************************= **** ************ ************************************************************************= **** ************* This E-mail is from = PANACYA Inc. The E-mail and any files transmitted with it are confidential and = may also be privileged and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized direct or indirect dissemination, distribution or copying of this message and any = attachments is strictly prohibited. If you have received the E-mail in error please notify adm...@pa... or telephone (410) 910-3300. ************************************************************************= **** ************ |
From: Mahler T. <tho...@it...> - 2002-05-28 13:00:11
|
Hi Arvind, =20 There is currently no public release containing a JDO implementation. Currently the JDO implementation can be checkout from our CVS = repository only. =20 The next public release (will come within 1 or 2 weeks) will contain = our latest JDO stuff. The current JDO implementatin is far from being complete. There is currently no schedule or time-line for a complete JDO impl. =20 HTH, =20 Thomas =20 -----Urspr=FCngliche Nachricht----- Von: Arvind Gudipati [mailto:Arv...@PA...] Gesendet: Dienstag, 28. Mai 2002 14:50 An: obj...@li... Betreff: [Objectbridge-jdo-dev] (no subject) Hi,=20 Is there any time-line for completion of JDO proposal for OJB? = Which build contains the current implementation of JDO based OJB? Was = wondering how complete is it? Arvind=20 ************************************************************************= **** ************* This E-mail is from = PANACYA Inc. The E-mail and any files transmitted with it are confidential and = may also be privileged and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized direct or indirect dissemination, distribution or copying of this message and any = attachments is strictly prohibited. If you have received the E-mail in error please notify adm...@pa... or telephone (410) 910-3300. ************************************************************************= **** ************ |
From: Arvind G. <Arv...@PA...> - 2002-05-28 12:50:17
|
Hi, Is there any time-line for completion of JDO proposal for OJB? Which build contains the current implementation of JDO based OJB? Was wondering how complete is it? Arvind **************************************************************************** ************* This E-mail is from PANACYA Inc. The E-mail and any files transmitted with it are confidential and may also be privileged and intended solely for the use of the individual or entity to whom they are addressed. Any unauthorized direct or indirect dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received the E-mail in error please notify adm...@pa... or telephone (410) 910-3300. **************************************************************************** ************ |
From: Brian W. <bw...@mc...> - 2002-05-28 10:11:14
|
Oops, noticed my last post contained non-ASCII characters which weren't very readable. Below is a cleaned up version of the original post. Also, since posting I noticed someone mentioned the need to map relationship related fields. The Forte tool does this as well. The convention it uses is: For fields that map to one instance of another class: class name starting with lower case letter (e.g. myClass) For fields that map to 0-n instances of another class: class name starting with lower case letter + "CollectionFor" + primary key property(ies) (e.g. if MyClass has a primary key field named myId, and the table mapped to MyClass has a table named MY_DETAIL_CLASS, the relationship field would be named myDetailClassCollectionForMyId) The above convention for 0-n is the 'complex cardinality' convention. One can also choose a 'simple cardinality', which leaves the "ForMyId" part off the name. -- Brian > Hi ojb developers, > > It=92s great to learn of your efforts to write an open-source JDO > product! Having used the free JDO stuff bundled with Forte for > Java 3.0, I=92m smitten by the benefits of JDO, but since JDO is > discontinued in the next release of Forte (now called Sun ONE), > I=92m looking for a replacement. I can=92t help out much with ojb > right now, as I=92m knee deep in a couple projects until at least > mid-Summer. So if you don=92t mind I=92ll mostly just keep reading > the dev mailing list. > > Having said this... I do have one possible small (code) > contribution. As you consider default mappings, you might > consider using the conventions used by the schema reverse > engineering tool bundled with Forte for Java (which generates > classes from an existing schema). This converts database schema > using underscores for word separators (e.g. MY_TABLE, > MY_COLUMN) into Java-like mixed case names (e.g. MyClass, > myProperty). This convention allows one to quickly set up JDO > objects to talk with an existing database schema without any > underscores in Java class names. If ojb used this convention, > ojb users with existing databases could use the Forte tool to > generate initial versions of their classes. I know such a > simple mapping (table to class, column to property) is > simplistic, etc., but it sure is a great way to get started. > Another option, if you=92re not comfortable with this particular > convention, is to add an extension tag to the *.jdo file > (perhaps at the package and/or class level) indicating that > this convention was in use. If you=92d like, I=92d be delighted to > contribute code and JUnit tests to the project that do these > conversions. > > I look forward to seeing your thoughts on the list related to > this idea on default mappings. > > Keep the faith! > > -- Brian > > Brian Westrich > McWest Corp. > bw...@mc... > 612-508-1827 > |
From: Mahler T. <tho...@it...> - 2002-05-28 07:50:54
|
> -----Urspr=FCngliche Nachricht----- > Von: Jason Hunter [mailto:jh...@se...] > Gesendet: Montag, 27. Mai 2002 21:12 > An: Pier Fumagalli > Cc: Jakarta General List > Betreff: Re: Objectbridge and JDO: Licensing issue >=20 >=20 > You basically have two choices. (1) You can use the Sun JAR files = and > comply with their license. Tomcat does this for several Sun=20 > JARs. Note > that sometimes the JARs have a "value add" clause that makes things a > little tricky, but it's doable. (2) You could do a clean room > implementation. It's the legal right to do #2 that was agreed to = with > Sun recently. Previously if you didn't like Sun's JAR=20 > license, you were > just stuck. Now you have the ability to implement a JSR on=20 > your own and > get access to the TCK. >=20 > -jh- >=20 > Pier Fumagalli wrote: > >=20 > > Florian, I believe that this is more-or-less (or falls=20 > really close) to the > > issue that XML-Axis is having (but I might be wrong, Sam?) > >=20 > > Maybe Jason (our liaison with the JCP) can give us some=20 > light on this topic? > >=20 > > Pier > >=20 > > "Florian Bruckner" <bf...@fl...> wrote: > >=20 > > > Hi, > > > > > > I am sending this to the jakarta-general list because I=20 > hope that some of > > > you can help us to resolve the following issue. > > > > > > As you might remember, Objectbridge was recently proposed as a > > > jakarta-subproject and accepted. This requires=20 > Objectbridge to change the > > > license to ASL, which is perfectly ok for everybody there. > > > > > > As far as I can see, a small problem arose a few days=20 > ago. Somebody added > > > two jar Files of Sun Microsystems related to JDO (Java=20 > Data Objects, an API > > > OJB plans to implement). One of those jars is of the reference > > > implementation of JDO, one is either from the reference=20 > implementation or > > > the specification. > > > > > > The following paragraphs is from an email I sent to the=20 > Objectbridge > > > Mailinglist, but unfortunately it didn't help to resolve=20 > our issue: > > > > > >> jdo.jar and jdori.jar are part of the reference=20 > implementation of JDO from > > >> Sun, and that is licensed unter the sun community source=20 > 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=20 > able the JDO part > > >> of OJB under these conditions and only for research.=20 > This implies that > > > we'll > > >> not be able to release a "production quality" version of=20 > OJB-JDO. What we > > >> jave to go for is a "clean-room" implementation, the=20 > 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=20 > viii contains a > > >> clause that this .jar mustn't be used by a clean-room=20 > implementation as > > > well > > >> (and that is our goal, isn't it?) > > > > > > Can we keep using these jars in Objectbridge or do we=20 > have to replace them > > > with our own implementation to do the move to ASL? > > > > > > TIA, > > > Florian Bruckner > > > > > -- > > [Perl] combines all the worst aspects of C and Lisp: a=20 > billion of different > > sublanguages in one monolithic executable. It combines=20 > the power of C with > > the readability of PostScript. [Jamie Zawinski - DNA Lounge=20 > - San Francisco] >=20 >=20 >=20 > -- > To unsubscribe, e-mail: =20 > <mailto:gen...@ja...> > For additional commands, e-mail:=20 > <mailto:gen...@ja...> >=20 |
From: Mahler T. <tho...@it...> - 2002-05-28 07:49:48
|
Hi Travis, > > > What would be the best way to configure the > persistencebrokers without having them read from the repository file? > Brokers actually don't rely on a repository.xml file but on a ojb.broker.metadata.DescriptorRepository! So the real question is: "How to build up a Descriptor repository from a .jdo file?" 1. step: in OJ.properties set repositoryFile=repository.jdo 2. step: change the method ojb.broker.metadata.RepositoryPersistor.readFromFile as follows public DescriptorRepository readFromFile(String filename) throws MalformedURLException, ParserConfigurationException, SAXException, IOException { if (filename.endsWith(".xml")) { return buildRepository(filename); } else if (filename.endsWith(".jdo")) { return buildRepositoryFromJdo(filename); } else { throw new PersistenceBrokerException("can't parse " + filename); } } 3. step: implement the new method private DescriptorRepository buildRepositoryFromJdo(String repositoryFileName) in this method you will parse the jdo file and generate a DecsriptorRepository from it. As far as I can see there is no need to have a extra classes like ojb.jdo.metadata.MetaClass as all this is already there in ojb.broker.metadata.ClassDescriptor. 4. change your JDOManagerFactory to use PersistenceBrokerFactory.createrBroker("repositoty.jdo") instead of "repository.xml". HTH, Thomas > Example: for jdo impl, the metadata gets read in, then when > calling PersistenceManagerFactory.getPersistenceManager() the > broker associated with the Manager should be filled > configured with the jdo metadata. > > 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: <tr...@th...> - 2002-05-27 21:30:12
|
What would be the best way to configure the persistencebrokers without having them read from the repository file? Example: for jdo impl, the metadata gets read in, then when calling PersistenceManagerFactory.getPersistenceManager() the broker associated with the Manager should be filled configured with the jdo metadata. Travis |
From: Christian S. <chr...@ne...> - 2002-05-27 21:22:56
|
the problem with #2 is that you would have to somehow link the items from both files, which has the potential of duplication information. So, like Thomas I also lean towards #1 (although I'm just a bystander currently). tr...@th... wrote: > Ya, and you can like represent objects and stuff, and it's really cool. ;-) > > Anyways, tried it and yes you are correct. Breaks. I was using crimson which obviously does not validate. Tried xerces and errored. > > Ok, so two options I guess: > > 1: Keep it in .jdo file: > > <field name="stock"> > <extension vendor-name="ojb" key="column" value="stock"> > <extension vendor-name="ojb" key="jdbc-type" value="INTEGER"> > </field> > > > Or 2: use external repository file and .jdo file. > > Maybe a vote? > > I'll go +1 on the jdo file (option 1) > > Travis > > ---- Original Message ---- > From: Christian Sell <chr...@ne...> > Sent: 2002-05-27 > To: obj...@li... > Subject: Re: RE: Re: [Objectbridge-jdo-dev] jdo extension format > > >>Well what I'm saying is that the xml file is still valid against the jdo > > dtd as key/value pair are optional in the extension > >>tag and we just extended a tag (which is what xml is all about). > > > What? XML is all about extending tags?? > > >>So the way we have specified it would not break any implementation and I'm > > not even sure if it's out of spec > because it still conforms. > > Not true. It does not conform, because you introduced 2 new attributes, > which are not in the DTD. Why dont you just create a sample file and run it > through a validating XML parser so you can see for yourself > > regards, Christian > > > _______________________________________________________________ > > 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 > > > > _______________________________________________________________ > > 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: Thomas M. <tho...@ho...> - 2002-05-27 20:17:24
|
+1 for the solution 1: (keep all metadata in .jdo file) cu, Thomas tr...@th... wrote: > Ya, and you can like represent objects and stuff, and it's really cool. ;-) > > Anyways, tried it and yes you are correct. Breaks. I was using crimson which obviously does not validate. Tried xerces and errored. > > Ok, so two options I guess: > > 1: Keep it in .jdo file: > > <field name="stock"> > <extension vendor-name="ojb" key="column" value="stock"> > <extension vendor-name="ojb" key="jdbc-type" value="INTEGER"> > </field> > > > Or 2: use external repository file and .jdo file. > > Maybe a vote? > > I'll go +1 on the jdo file (option 1) > > Travis > > ---- Original Message ---- > From: Christian Sell <chr...@ne...> > Sent: 2002-05-27 > To: obj...@li... > Subject: Re: RE: Re: [Objectbridge-jdo-dev] jdo extension format > > >>Well what I'm saying is that the xml file is still valid against the jdo >> > dtd as key/value pair are optional in the extension > >>tag and we just extended a tag (which is what xml is all about). >> > > What? XML is all about extending tags?? > > >>So the way we have specified it would not break any implementation and I'm >> > not even sure if it's out of spec > because it still conforms. > > Not true. It does not conform, because you introduced 2 new attributes, > which are not in the DTD. Why dont you just create a sample file and run it > through a validating XML parser so you can see for yourself > > regards, Christian > > > _______________________________________________________________ > > 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 > > > > _______________________________________________________________ > > 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-27 20:08:52
|
At what point should a PersistenceCapable instance get assigned a StateManager? Travis |
From: <tr...@th...> - 2002-05-27 19:23:48
|
Ya, and you can like represent objects and stuff, and it's really cool. ;-) Anyways, tried it and yes you are correct. Breaks. I was using crimson which obviously does not validate. Tried xerces and errored. Ok, so two options I guess: 1: Keep it in .jdo file: <field name="stock"> <extension vendor-name="ojb" key="column" value="stock"> <extension vendor-name="ojb" key="jdbc-type" value="INTEGER"> </field> Or 2: use external repository file and .jdo file. Maybe a vote? I'll go +1 on the jdo file (option 1) Travis ---- Original Message ---- From: Christian Sell <chr...@ne...> Sent: 2002-05-27 To: obj...@li... Subject: Re: RE: Re: [Objectbridge-jdo-dev] jdo extension format > Well what I'm saying is that the xml file is still valid against the jdo dtd as key/value pair are optional in the extension > tag and we just extended a tag (which is what xml is all about). What? XML is all about extending tags?? >So the way we have specified it would not break any implementation and I'm not even sure if it's out of spec because it still conforms. Not true. It does not conform, because you introduced 2 new attributes, which are not in the DTD. Why dont you just create a sample file and run it through a validating XML parser so you can see for yourself regards, Christian _______________________________________________________________ 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: Christian S. <chr...@ne...> - 2002-05-27 17:54:23
|
> Well what I'm saying is that the xml file is still valid against the jdo dtd as key/value pair are optional in the extension > tag and we just extended a tag (which is what xml is all about). What? XML is all about extending tags?? >So the way we have specified it would not break any implementation and I'm not even sure if it's out of spec because it still conforms. Not true. It does not conform, because you introduced 2 new attributes, which are not in the DTD. Why dont you just create a sample file and run it through a validating XML parser so you can see for yourself regards, Christian |
From: <tr...@th...> - 2002-05-27 16:35:54
|
Well what I'm saying is that the xml file is still valid against the jdo dtd as key/value pair are optional in the extension tag and we just extended a tag (which is what xml is all about). So the way we have specified it would not break any implementation and I'm not even sure if it's out of spec because it still conforms. I started up a topic at jdocentral to get some feedback on this. If this does break spec, then we could do something like this: <extension vendor-name="ojb" key="repository" value="repository.xml"> Or something like that anyways. Travis ---- Original Message ---- From: Christian Sell <nc-...@ne...> Sent: 2002-05-27 To: obj...@li... Subject: RE: Re: [Objectbridge-jdo-dev] jdo extension format >Doh! ;-) > >That's not very good. Although having it the way we specified shouldn't harm anything should it? > It wouldnt harm anything except JDO compliance. But as far as I remember, that was the whole point, wasn't it? What about the option of maintaining a separate file? >Be a pain to use the key/value pair when having an extension like this: > > <extension vendor-name="ojb" > platform="hsqldb" > jdbc-level="2.0" > driver="org.hsqldb.jdbcDriver" > protocol="jdbc" > subprotocol="hsqldb" > dbalias="../OJB" > username="sa" > password="" > /> > >Travis > >---- Original Message ---- >From: Sebastian Kanthak <seb...@mu...> >Sent: 2002-05-26 >To: obj...@li... >Subject: Re: [Objectbridge-jdo-dev] jdo extension format > >Hi Travis, > >On Sunday 26 May 2002 02:10, tr...@th... wrote: >> So for consistency's sake, I propose the new names like so: >> >> <extension vendor-name="ojb" table-name="Product"/> >> >> <extension vendor-name="ojb" column-name="stock" jdbc- type="INTEGER"/> > >this won't be spec compliant as the DTD definition for extension is: > ><!ELEMENT extension (extension)*> ><!ATTLIST extension vendor-name CDATA #REQUIRED> ><!ATTLIST extension key CDATA #IMPLIED> ><!ATTLIST extension value CDATA #IMPLIED> > >so, it would have to be more like this: > ><extension vendor-name="ojb" key="table-name" value="Product"/> > >Note, that you can nest extension-elements if this should be necessary to >match more complex mapping-attributes. > >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 > > > >_____________________________________________________________ __ > >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 _______________________________________________________________ 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-27 08:03:02
|
Hi Christian, > -----Urspr=FCngliche Nachricht----- > Von: Christian Sell [mailto:nc-...@ne...] > Gesendet: Montag, 27. Mai 2002 09:45 > An: obj...@li... > Cc: obj...@li... > Betreff: RE: Re: [Objectbridge-jdo-dev] jdo extension format >=20 >=20 > >Doh! ;-) > > > >That's not very good. Although having it the way we=20 > specified shouldn't harm anything should it? =20 > > >=20 > It wouldnt harm anything except JDO compliance. But as far as=20 > I remember, that was the whole point, wasn't it?=20 That's a good point! We started this thread with "Take JDO serious and = use a *.jdo file as the single point of keeping metadata." If we take the JDO Spec serious me should stick 100% to the rules, everything else just makes no sense! =20 > What about=20 > the option of maintaining a separate file? >=20 That's my original suggestion. Maybe it was not that bad ? Thomas >=20 > >Be a pain to use the key/value pair when having an extension=20 > like this: > > > > <extension vendor-name=3D"ojb" > > platform=3D"hsqldb" > > jdbc-level=3D"2.0" > > driver=3D"org.hsqldb.jdbcDriver" > > protocol=3D"jdbc" > > subprotocol=3D"hsqldb" > > dbalias=3D"../OJB" > > username=3D"sa" > > password=3D"" > > /> > > > >Travis > > > >---- Original Message ---- > >From: Sebastian Kanthak <seb...@mu...> > >Sent: 2002-05-26 > >To: obj...@li... > >Subject: Re: [Objectbridge-jdo-dev] jdo extension format > > > >Hi Travis, > > > >On Sunday 26 May 2002 02:10, tr...@th... wrote: > >> So for consistency's sake, I propose the new names like so: > >> > >> <extension vendor-name=3D"ojb" table-name=3D"Product"/> > >> > >> <extension vendor-name=3D"ojb" column-name=3D"stock" jdbc- > type=3D"INTEGER"/> > > > >this won't be spec compliant as the DTD definition for=20 > extension is: > > > ><!ELEMENT extension (extension)*> > ><!ATTLIST extension vendor-name CDATA #REQUIRED> > ><!ATTLIST extension key CDATA #IMPLIED> > ><!ATTLIST extension value CDATA #IMPLIED> > > > >so, it would have to be more like this: > > > ><extension vendor-name=3D"ojb" key=3D"table-name"=20 > value=3D"Product"/> > > > >Note, that you can nest extension-elements if this should be=20 > necessary to=20 > >match more complex mapping-attributes. > > > >ciao Sebastian > > > >--=20 > >Sebastian Kanthak | seb...@mu... > > > >_____________________________________________________________ > __ > > > >Don't miss the 2002 Sprint PCS Application Developer's=20 > Conference > >August 25-28 in Las Vegas --=20 > http://devcon.sprintpcs.com/adp/index.cfm > > > >_______________________________________________ > >Objectbridge-jdo-dev mailing list > >Obj...@li... > >https://lists.sourceforge.net/lists/listinfo/objectbridge- > jdo-dev > > > > > > > >_____________________________________________________________ > __ > > > >Don't miss the 2002 Sprint PCS Application Developer's=20 > Conference > >August 25-28 in Las Vegas --=20 > http://devcon.sprintpcs.com/adp/index.cfm > > > >_______________________________________________ > >Objectbridge-jdo-dev mailing list > >Obj...@li... > >https://lists.sourceforge.net/lists/listinfo/objectbridge- > jdo-dev >=20 > _______________________________________________________________ >=20 > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- = http://devcon.sprintpcs.com/adp/index.cfm >=20 > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev >=20 |
From: Christian S. <nc-...@ne...> - 2002-05-27 07:45:04
|
>Doh! ;-) > >That's not very good. Although having it the way we specified shouldn't harm anything should it? > It wouldnt harm anything except JDO compliance. But as far as I remember, that was the whole point, wasn't it? What about the option of maintaining a separate file? >Be a pain to use the key/value pair when having an extension like this: > > <extension vendor-name="ojb" > platform="hsqldb" > jdbc-level="2.0" > driver="org.hsqldb.jdbcDriver" > protocol="jdbc" > subprotocol="hsqldb" > dbalias="../OJB" > username="sa" > password="" > /> > >Travis > >---- Original Message ---- >From: Sebastian Kanthak <seb...@mu...> >Sent: 2002-05-26 >To: obj...@li... >Subject: Re: [Objectbridge-jdo-dev] jdo extension format > >Hi Travis, > >On Sunday 26 May 2002 02:10, tr...@th... wrote: >> So for consistency's sake, I propose the new names like so: >> >> <extension vendor-name="ojb" table-name="Product"/> >> >> <extension vendor-name="ojb" column-name="stock" jdbc- type="INTEGER"/> > >this won't be spec compliant as the DTD definition for extension is: > ><!ELEMENT extension (extension)*> ><!ATTLIST extension vendor-name CDATA #REQUIRED> ><!ATTLIST extension key CDATA #IMPLIED> ><!ATTLIST extension value CDATA #IMPLIED> > >so, it would have to be more like this: > ><extension vendor-name="ojb" key="table-name" value="Product"/> > >Note, that you can nest extension-elements if this should be necessary to >match more complex mapping-attributes. > >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 > > > >_____________________________________________________________ __ > >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: Mika R. <mri...@ya...> - 2002-05-27 07:40:19
|
> In fact we already have a working JDO prototype > implementation ! Sounds great. > just curious: why do you use Jiapi instead of the > defact-standard BCEL? As a matter of fact,we are using BCEL. Jiapi is based on BCEL. We started Jiapi project allmost a year ago. With prototyping with BCEL. Jiapi provides greater level of abstraction than BCEL. With Jiapi, you do not talk about ConstantPool and all those low-level stuff. Jiapi is more like Read-Write reflection API. And it utilizes BCEL to do all the wiring needed. There is also a framework for instrumenting classes. Framework is implemented as filter design pattern. > What exactly is your enhancer doing? is it > generating the same things as > the JDORI enhancer? Yes. Take a look at PersistenCapableTemplate: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jadoe/jadoe/src/alt/jadoe/PersistenceCapableTemplate.java?rev=1.3&content-type=text/vnd.viewcvs-markup Methods/fields in this class gets copied into enhanced class. There are some methods, that will have to be added by other means, and these are missing. The things we will do with Jadoe: a) Finalize missing field/method generation. b) Provide a way to interface with the enhancer. We are running Jadoe from command line, and it will dump modified classes into filesystem. So that we can easily inspect them. c) Consider adding MBean interface for enhanced classes. This would naturally be an option. - Mika Riekkinen - __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
From: Mahler T. <tho...@it...> - 2002-05-27 07:28:05
|
Hi, AFAIK JDO does not specify what kind of Object an ObjectId should be. So IMO it's OK to use an ojb.broker.Identity cheers, Thomas > -----Urspr=FCngliche Nachricht----- > Von: tr...@th... [mailto:tr...@th...] > Gesendet: Sonntag, 26. Mai 2002 03:16 > An: obj...@so... > Betreff: [Objectbridge-jdo-dev] ObjectId >=20 >=20 > Anyone have any insight into the ObjectId in the jdo spec? >=20 > I am just using an instance of an object with the id of that=20 > object set as this seems to be what ojb is using. =20 >=20 > Travis=20 >=20 > _______________________________________________________________ >=20 > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- = http://devcon.sprintpcs.com/adp/index.cfm >=20 > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev >=20 |
From: <tr...@th...> - 2002-05-26 23:44:01
|
Doh! ;-) That's not very good. Although having it the way we specified shouldn't harm anything should it? Be a pain to use the key/value pair when having an extension like this: <extension vendor-name="ojb" platform="hsqldb" jdbc-level="2.0" driver="org.hsqldb.jdbcDriver" protocol="jdbc" subprotocol="hsqldb" dbalias="../OJB" username="sa" password="" /> Travis ---- Original Message ---- From: Sebastian Kanthak <seb...@mu...> Sent: 2002-05-26 To: obj...@li... Subject: Re: [Objectbridge-jdo-dev] jdo extension format Hi Travis, On Sunday 26 May 2002 02:10, tr...@th... wrote: > So for consistency's sake, I propose the new names like so: > > <extension vendor-name="ojb" table-name="Product"/> > > <extension vendor-name="ojb" column-name="stock" jdbc-type="INTEGER"/> this won't be spec compliant as the DTD definition for extension is: <!ELEMENT extension (extension)*> <!ATTLIST extension vendor-name CDATA #REQUIRED> <!ATTLIST extension key CDATA #IMPLIED> <!ATTLIST extension value CDATA #IMPLIED> so, it would have to be more like this: <extension vendor-name="ojb" key="table-name" value="Product"/> Note, that you can nest extension-elements if this should be necessary to match more complex mapping-attributes. 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-26 23:39:57
|
Ok, Will use new repository style grammar. travis ---- Original Message ---- From: Thomas Mahler <tho...@ho...> Sent: 2002-05-26 To: obj...@li... Subject: Re: [Objectbridge-jdo-dev] jdo extension format Hi Travis tr...@th... wrote: > Thomas, > > with regards to extension naming, i'm thinking that using the ojb > repository naming conventions like table vs. table-name won't > really match, because you also have column.name and jdbc_type which > seems a little inconsistent. > You are referring to the *OLD* repository grammar. I was talking about the *new* grammar. (See attached dtd-file) I'm currently patching OJB to use this new grammar! This file contains the new grammar hopefully free of any syntactic inconsistencies. I strongly recommend to use atribute-names from this grammar like: <extension vendor-name="ojb" table="Product"/> <extension vendor-name="ojb" column="stock" jdbc-type="INTEGER"/> cheers, Thomas > So for consistency's sake, I propose the new names like so: > > <extension vendor-name="ojb" table-name="Product"/> > > <extension vendor-name="ojb" column-name="stock" > jdbc-type="INTEGER"/> > > It's more descriptive and matches the jdo naming conventions. > > 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: Sebastian K. <seb...@mu...> - 2002-05-26 11:03:03
|
Hi Travis, On Sunday 26 May 2002 02:10, tr...@th... wrote: > So for consistency's sake, I propose the new names like so: > > <extension vendor-name="ojb" table-name="Product"/> > > <extension vendor-name="ojb" column-name="stock" jdbc-type="INTEGER"/> this won't be spec compliant as the DTD definition for extension is: <!ELEMENT extension (extension)*> <!ATTLIST extension vendor-name CDATA #REQUIRED> <!ATTLIST extension key CDATA #IMPLIED> <!ATTLIST extension value CDATA #IMPLIED> so, it would have to be more like this: <extension vendor-name="ojb" key="table-name" value="Product"/> Note, that you can nest extension-elements if this should be necessary to match more complex mapping-attributes. ciao Sebastian -- Sebastian Kanthak | seb...@mu... |
From: Thomas M. <tho...@ho...> - 2002-05-26 08:53:46
|
Hi Travis tr...@th... wrote: > Thomas, > > with regards to extension naming, i'm thinking that using the ojb > repository naming conventions like table vs. table-name won't > really match, because you also have column.name and jdbc_type which > seems a little inconsistent. > You are referring to the *OLD* repository grammar. I was talking about the *new* grammar. (See attached dtd-file) I'm currently patching OJB to use this new grammar! This file contains the new grammar hopefully free of any syntactic inconsistencies. I strongly recommend to use atribute-names from this grammar like: <extension vendor-name="ojb" table="Product"/> <extension vendor-name="ojb" column="stock" jdbc-type="INTEGER"/> cheers, Thomas > So for consistency's sake, I propose the new names like so: > > <extension vendor-name="ojb" table-name="Product"/> > > <extension vendor-name="ojb" column-name="stock" > jdbc-type="INTEGER"/> > > It's more descriptive and matches the jdo naming conventions. > > 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: <tr...@th...> - 2002-05-26 01:22:03
|
Anyone have any insight into the ObjectId in the jdo spec? I am just using an instance of an object with the id of that object set as this seems to be what ojb is using. Travis |