objectbridge-jdo-dev Mailing List for ObJectRelationalBridge (Page 2)
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: Juozas B. <ba...@ma...> - 2002-06-14 16:40:32
|
Hi, I work on experimental persistence framework, it is Apache SimpleStore. It has implementation for JDBC, XMLDB and file. May be it is possible to merge both projects ? It is nothing bad to have two or more projects about the same, but I think it is good to find something the most usefull and reuse it. I prefer to have three or more projects at Apache : 1) Standard Apache DB API, only interfaces and "large" documentation. 2) Implementations and "small" documentation. JDO can be some kind of "standard" API, but it closed for people like me and I prefer Open Standards. Hi David, > -----Ursprüngliche Nachricht----- > Von: David Zejda [mailto:dv...@at...] > Gesendet: Donnerstag, 13. Juni 2002 01:17 > An: Obj...@li... > Betreff: [Objectbridge-jdo-dev] Non-JDBC data sources > > > I know, that OJB's focus sharpness (faq: It's concerned with > O/R mapping and > nothing else.) is design/manage advantage, but I work on > project, where it's > crucial to integrate disparate data sources (RDBMS, ODBMS, > XML based DBMS, > flat-files, vendor specific formats..). I decided not to use closed, > non-free solutions at all, so OJB (open-source, clearly designed, > scalable...), seems to be suitable as a persistency-heart. > Could you advise how to get on with OJB? > 1) use OJB as a single persistency adaptor, manage several ODMG > implementations, make some fascade to hide it, e.g. solve distributed > transactions...? If there are existing ODMG Java bindings to you other datasources this will be vers easy. Just write litte wrappers that route user request to different ODMG implementations. If there is no ODMG API for a given persistent store, you can implement a dedicated PersistenceBroker for this special persistent store. This way you can use the OJB ODMG (or JDO if you prefer) implementation to access arbitrary persistent stores. > 2) extent OJB (add persistency adpators to OJB) - if > publically useful, > release them under LGPL as modular OJB's parts/add-ons? Yes, that's what I'm recommending. have a look at our persistence kernel interface ojb.broker.PersistenceBroker. It contains no specifics for RDBMS. It is a generic abstractiion of an object store. There could be implementations for OODBMS, RDBMS, XML databases, file system or Directory Services ! You only have to provide a persistent store specific PersistenceBroker Implementation. Than you can use the OJB ODMG or JDO layer to work against those specific brokers. regarding OJB scope: As OJB will be one of the foundation projects of the new db.apache.org site, our scope is not longer limited as mentioned in the faq. OJB will be a generic object persistence integration platform! Thus having new PersistenceBroker implementations is very interesting for us! (especially XML, OODBMS, LDAP, flat-file) As we are moving to Jakarta, we will use the apache licence soon. > 2.1) is this posible without (negative) impact on OJB's actual design yes no problems! > 3) something else? > > In the roadmap there is (4me) a bit mysterious sentence "provide > distributed Meta-Object Protocol access through PersistenceBroker API" This has been implemented a long time ago. OJB comes with a client/server mode. To have fully operational clients it is necessary to have meta-data on the client too. This was not possible in the early days, but now it is. > Somewhere in OJB doc I read about possibility to build my own > PersistenceManager. Does it relate to mentioned problem? > No. You simply have to implement the PersistenceBroker interface to write a new storage adaptor. A persistenceManager would be something like your own ODMG or JDO implementation. That would be a much more difficult task! cheers, Thomas > Thanks for reply > David Zejda > > > PS: I know, I can suck all wanted info from API, but I thing, you (OJB > experts) can answer quickly and painlessly. > > BTW thanks for OJB, well done! > > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - > http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > 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?source=dntextlink _______________________________________________ Objectbridge-jdo-dev mailing list Obj...@li... https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev |
From: Mahler T. <tho...@it...> - 2002-06-14 08:56:04
|
Hi David, > -----Urspr=FCngliche Nachricht----- > Von: David Zejda [mailto:dv...@at...] > Gesendet: Donnerstag, 13. Juni 2002 01:17 > An: Obj...@li... > Betreff: [Objectbridge-jdo-dev] Non-JDBC data sources >=20 >=20 > I know, that OJB's focus sharpness (faq: It's concerned with=20 > O/R mapping and > nothing else.) is design/manage advantage, but I work on=20 > project, where it's > crucial to integrate disparate data sources (RDBMS, ODBMS,=20 > XML based DBMS, > flat-files, vendor specific formats..). I decided not to use closed, > non-free solutions at all, so OJB (open-source, clearly designed, > scalable...), seems to be suitable as a persistency-heart. > Could you advise how to get on with OJB? > 1) use OJB as a single persistency adaptor, manage several ODMG > implementations, make some fascade to hide it, e.g. solve distributed > transactions...? If there are existing ODMG Java bindings to you other datasources this = will be vers easy. Just write litte wrappers that route user request to different ODMG implementations. If there is no ODMG API for a given persistent store, you can implement = a dedicated PersistenceBroker for this special persistent store. This way you can use the OJB ODMG (or JDO if you prefer) implementation = to access arbitrary persistent stores. > 2) extent OJB (add persistency adpators to OJB) - if=20 > publically useful, > release them under LGPL as modular OJB's parts/add-ons? Yes, that's what I'm recommending. have a look at our persistence = kernel interface ojb.broker.PersistenceBroker. It contains no specifics for RDBMS. It is a generic abstractiion of an object store. There could be implementations for OODBMS, RDBMS, XML databases, file = system or Directory Services !=20 You only have to provide a persistent store specific PersistenceBroker Implementation. Than you can use the OJB ODMG or JDO layer to work against those = specific brokers. regarding OJB scope: As OJB will be one of the foundation projects of the new db.apache.org = site, our scope is not longer limited as mentioned in the faq. OJB will be a generic object persistence integration platform! Thus having new PersistenceBroker implementations is very interesting = for us! (especially XML, OODBMS, LDAP, flat-file) As we are moving to Jakarta, we will use the apache licence soon. > 2.1) is this posible without (negative) impact on OJB's actual design yes no problems!=20 > 3) something else? >=20 > In the roadmap there is (4me) a bit mysterious sentence "provide > distributed Meta-Object Protocol access through PersistenceBroker = API" This has been implemented a long time ago. OJB comes with a = client/server mode. To have fully operational clients it is necessary to have = meta-data on the client too. This was not possible in the early days, but now it is. > Somewhere in OJB doc I read about possibility to build my own > PersistenceManager. Does it relate to mentioned problem? >=20 No. You simply have to implement the PersistenceBroker interface to = write a new storage adaptor. A persistenceManager would be something like your own ODMG or JDO implementation. That would be a much more difficult task! cheers, Thomas > Thanks for reply > David Zejda >=20 >=20 > PS: I know, I can suck all wanted info from API, but I thing, you = (OJB > experts) can answer quickly and painlessly. >=20 > BTW thanks for OJB, well done! >=20 >=20 >=20 >=20 > _______________________________________________________________ >=20 > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -=20 > http://devcon.sprintpcs.com/adp/index.cfm?source=3Dosdntextlink >=20 > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev >=20 |
From: David Z. <dv...@at...> - 2002-06-13 20:13:41
|
I know, that OJB's focus sharpness (faq: It's concerned with O/R mapping and nothing else.) is design/manage advantage, but I work on project, where it's crucial to integrate disparate data sources (RDBMS, ODBMS, XML based DBMS, flat-files, vendor specific formats..). I decided not to use closed, non-free solutions at all, so OJB (open-source, clearly designed, scalable...), seems to be suitable as a persistency-heart. Could you advise how to get on with OJB? 1) use OJB as a single persistency adaptor, manage several ODMG implementations, make some fascade to hide it, e.g. solve distributed transactions...? 2) extent OJB (add persistency adpators to OJB) - if publically useful, release them under LGPL as modular OJB's parts/add-ons? 2.1) is this posible without (negative) impact on OJB's actual design 3) something else? In the roadmap there is (4me) a bit mysterious sentence "provide distributed Meta-Object Protocol access through PersistenceBroker API" Somewhere in OJB doc I read about possibility to build my own PersistenceManager. Does it relate to mentioned problem? Thanks for reply David Zejda PS: I know, I can suck all wanted info from API, but I thing, you (OJB experts) can answer quickly and painlessly. BTW thanks for OJB, well done! |
From: <tr...@th...> - 2002-06-12 19:21:59
|
Can someone take a quick look at this, I can't seem to figure it out. The enhancer is finishing the enhance job with no errors, but also, not enhancing the file. If you run the enhance ant task, you should see the classfile not changed note. Any ideas? Travis |
From: <tr...@th...> - 2002-06-10 05:16:43
|
2 Reasons for doing this: 1. repository_internal.xml is still needed. 2. Will allow us to add more internal mappings if needed. The user if using the jdo implementation would not need to touch the repos files. He would simply make the jdo file. How to do this? Move this: if(filename.endsWith(".jdo")){ from RepositoryPersister.readFromFile to DescriptorRepository.getInstance. In getInstance, do something like this: _instance = persistor.readFromFile(repositoryFileName); now check for jdo extension and load jdo file in as well, not to replace, just in addition. Thoughts? Travis |
From: Thomas M. <tho...@ho...> - 2002-06-06 17:30:26
|
Welcome Christian! Christian Bauer wrote: > I just subscribed to this list, after I tried the new 0.9 release of > OJB. I'm particulary interested in the JDO functionality, as I see the > need for a free and open source implementation of this new > specification. > > My primary work focus is OO software design and programming, I'm > currently evaluating different strategies and technologies for > persistent object storage and retrieval in information systems (all > based on Java). > > I evaluated different CMP implementations for Entity Beans with EJB 2.0 > and proprietary extensions, commercial proprietary O/R mapping tools, > free O/R mapping tools (Castor) and all possible JDBC implementation > strategies. > > I finally realized that the SUN JDO specification is what I was looking > for, but all commercial implementations lack either quality or > documentation, often both. Most of the time I was lucky to get through to > the evaluation download page at all... > We even don't have a full implementation yet, not to speak of documentation ;-) > So, I'm offering my help with the JDO support in OJB, because a well > understood and free/open source implementation is required as a > counterweight to the commercial implementations. > fine! You can start by having a look at Travis prototype implementation, studying the JDORI by SUN and by studying the OJB ODMG implementation to learn how an object transaction manager can be build with OJB. Of course you are invited to participate in our discussions and to contribute ideas and code ! cheers, Thomas > |
From: Christian B. <chr...@bl...> - 2002-06-06 14:43:45
|
I just subscribed to this list, after I tried the new 0.9 release of OJB. I'm particulary interested in the JDO functionality, as I see the need for a free and open source implementation of this new specification. My primary work focus is OO software design and programming, I'm currently evaluating different strategies and technologies for persistent object storage and retrieval in information systems (all based on Java). I evaluated different CMP implementations for Entity Beans with EJB 2.0 and proprietary extensions, commercial proprietary O/R mapping tools, free O/R mapping tools (Castor) and all possible JDBC implementation strategies. I finally realized that the SUN JDO specification is what I was looking for, but all commercial implementations lack either quality or documentation, often both. Most of the time I was lucky to get through to the evaluation download page at all... So, I'm offering my help with the JDO support in OJB, because a well understood and free/open source implementation is required as a counterweight to the commercial implementations. -- BLUE MARS - Gesellschaft für digitale Kommunikation mbH Christian Bauer mailto:chr...@bl... Technology Department http://www.bluemars.de Ebersheimstrasse 5 Tel: +49 (0)69 469973-00 60320 Frankfurt/M. Fax: +49 (0)69 469973-99 |
From: Leandro R. S. C. <le...@ib...> - 2002-06-05 18:02:39
|
On Tue, 2002-06-04 at 04:51, Mahler Thomas wrote: > Hi all, Hi > =20 > after some minor problems I managed to assemble a new release. > As I had to fix several bugs to get this release stable, I did not find t= he > time to keep the documentation up to date. > In particular the documentation regarding the repository is out of sync d= ue > to the redesigned repository.dtd. I trying to make ojb-1-0 work with my app. I can help you with the docs if you want. > =20 > Lasse Lindg=E5rd wrote a stylesheet to transform existing repositories to= the > new syntax. I hope this will help users to migrate quickly! >=20 > >From the relase notes: >=20 > Changes in Release 0.9 >=20 >=20 >=20 > new features: > ... > bug fixes: > ... > Refactorings: > ... >=20 > With this release we are feature complete for the 1.0 release! >=20 > For 1.0 you should not expect more features to be added. >=20 I agree with you. One thing I'd like to change in OJB is exception handling. There are many places where Throwable is caught ! That is no good ! We could change the way exceptions are handled and provide better error reporting/logging ! I voluntier to do that ! >=20 > cheers, > =20 > Thomas > =20 --=20 Leandro Rodrigo Saad Cruz IT - Inter Business Tecnologia e Servicos (IB) http://www.ibnetwork.com.br |
From: <tr...@th...> - 2002-06-04 15:15:55
|
Can someone try running the latest jdo sample app and see if you can figure out why the DescriptorRepository is being set to null. Try adding an item then listing them to see the error. It could be the way I am setting up the repository in OjbJdoXmlHandler. Travis |
From: Mahler T. <tho...@it...> - 2002-06-04 07:52:17
|
Hi all, =20 after some minor problems I managed to assemble a new release. As I had to fix several bugs to get this release stable, I did not find = the time to keep the documentation up to date. In particular the documentation regarding the repository is out of sync = due to the redesigned repository.dtd. =20 Lasse Lindg=E5rd wrote a stylesheet to transform existing repositories = to the new syntax. I hope this will help users to migrate quickly! From the relase notes: Changes in Release 0.9 new features: - Servlet Implementation of PersistenceBrokerServer, allows to easily deploy the OJB Server as a normal Http-Servlet - JDO prototype and sample application. Cuurently we are using the bytecode enhancer from the JDO Reference Implementation. We are not allowed to ship the jdori.jar from SUN's reference implementation. If you play around with our JDO sample, just download jdori.jar from = SUN and add it to the ojb-0-9/lib directory! - complete redesign of the repository grammar. To help users to migrate their existing repository.xml files we provide a XSLT stylesheet (see ojb-0-9/src/test/test/ojb/0.8to0.9.xsl) - performance test-suite for the ODMG implementation - Full JTA and JCA integration! - PersistenceBroker interface now extends the org.odbms.ObjectContainer interface to provide a better integration for the S.O.D.A query API. bug fixes: - tons of bug fixes Refactorings: - performance enhancements - redesign of SqlGenerator - redesign of the build process, now using Torque and Maven - redesign of Repository parser - ConversionStrategies have been moved from the class-level to the field-level.=20 With this release we are feature complete for the 1.0 release! For 1.0 you should not expect more features to be added. In OJB 1.0 we will have more bug fixes, better documentation and we = will add the=20 prefix "org.apache" to all ojb packages to reflect our new home at = Jakarta. Important note: We did not yet change the documentation to reflect the changes to the repository.dtd. We will try to correct it asap. cheers, =20 Thomas =20 |
From: <tr...@th...> - 2002-05-30 18:57:58
|
When I run the app after building the repos from jdo file, The repos seems to be fine until I call a getCollectionByQuery() (probably other things would cause the same thing to happen). before calling: REPOS: DescriptorRepository JdbcConnectionDescriptor hsqldb org.hsqldb.jdbcDriver jdbc hsqldb ../OJB sa {class test.ojb.tutorial4.Product=table: Product FieldDescriptions: [Lojb.broker.metadata.FieldDescriptor;@174b07} after calling: REPOS: null java.lang.NullPointerException at ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:958) at ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1061) at ojb.broker.singlevm.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1048) Any ideas? It seems that DescriptorRepository descriptorRepository in PersistenceBrokerImpl is getting set to null for some reason? Travis |
From: <tr...@th...> - 2002-05-30 03:04:05
|
Any ideas on what we should do to repository_internal.xml for jdo? Travis |
From: Thomas M. <tho...@ho...> - 2002-05-29 23:17:53
|
Hi Travis, IMO it should work as the ODMG implementation that is: 1. auto-retrieve="true" to load depending objects (or proxies if so configured) 2. auto-update="false" and auto-delete="false". Setting these to "true" won't be needed as JDO as well as ODMG provides a "dirty-detection". Thus the transaction knows if dependend objects need to be updated or deleted, without forcing the PersistenceBroker to do so. These are the default settings. That is if you don't declare any auto-* attributes these settings are chosen implicitely. cheers, Thomas tr...@th... wrote: > Should jdo have default auto retrieve and update, etc? > > 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-29 22:14:52
|
Should jdo have default auto retrieve and update, etc? Travis |
From: Schier, D. <dar...@in...> - 2002-05-29 06:10:19
|
The toolset for metadata operations seems to be pretty interesting. I don't know of any product that is able to do a real schema migration out of the box, in sense of keeping the data but migrating the schema. (Reverse)Engineering of db/.class/DDL and vice versa is the first step, adding columns (on the fly or through pushing a button) is the second creating a transport out of the box, that is able to cope with foreign = keys, constraints, renaming of columns and all these database bells and = whistles=20 is a pretty challenging (and interesting) task. Regards Darius -----Urspr=FCngliche Nachricht----- Von: Thomas Mahler [mailto:tho...@ho...]=20 Gesendet: Dienstag, 28. Mai 2002 22:42 An: obj...@li... Betreff: Re: [Objectbridge-jdo-dev] Object store (automated database creation) Hi Travis tr...@th... wrote: > 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? > Yes, That's cool idea.In certain production environments it won't be=20 allowed to create tables on the fly (e.g. in my company all database=20 tables you want to be created must be qa'ed by the DBA team...). But for all others this kind of thing could be quite helpful. I'm planing to have a whole toolset for metadata operations in OJB 2.0. This toolset will allow to - forward engineer java classes to Metadata and DDL (possibly with on=20 the fly generation in the db) With this kind of tool it will be easy to build for instance a=20 persistent XML DOM implementation as one would need in an XML data=20 server... (this is one of the demos that's on my todo list for a very=20 long time...) - reverse engineering from relational database to Java classes and = Metadata - a Mapping workbench to allow manual mapping from Java classes to = RDBMS=20 tables. Of course it must also be possible to parse *.jdo files to Ojb Metadata = and to generat *.jdo files from the MetaData layer. This can be done by extending the RepositoryPersistor. So there will be a lot of interesting things to do for OJB 2.0 ... cheers, 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...=20 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-28 23:04:56
|
We're going down the all encompassing jdo file road for now. Travis ---- Original Message ---- From: Andy Lewis <aj...@as...> Sent: 2002-05-28 To: obj...@li... Subject: Re: AW: Re: [Objectbridge-jdo-dev] jdo extension format > hi, > > Andy Lewis wrote: > > <snip> >> I'm still missing something here - it sounds like everything can be >> handled in the JDO file, but that it simply becomes very verbose. >> >> Is that accurate? >> > > > I think you are right: > > This JDO file must keep all information, currently in the > repository.xml file. > As we are bound to the JDO extension mechanism this JDO file won't be > as concise as a repository.xml. > > Thomas ok...so I'd say we go with the JDO file - even though it is not as easy to read. If that become a huge issue, perhasp someone could through together an XSLT stylesheet to make it presentable... :) "The heights of genius are only measurable by the depths of stupidity." _______________________________________________________________ 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: Andy L. <aj...@as...> - 2002-05-28 22:56:00
|
> hi, > > Andy Lewis wrote: > > <snip> >> I'm still missing something here - it sounds like everything can be >> handled in the JDO file, but that it simply becomes very verbose. >> >> Is that accurate? >> > > > I think you are right: > > This JDO file must keep all information, currently in the > repository.xml file. > As we are bound to the JDO extension mechanism this JDO file won't be > as concise as a repository.xml. > > Thomas ok...so I'd say we go with the JDO file - even though it is not as easy to read. If that become a huge issue, perhasp someone could through together an XSLT stylesheet to make it presentable... :) "The heights of genius are only measurable by the depths of stupidity." |
From: Andy L. <aj...@as...> - 2002-05-28 22:52:31
|
news.solarmetric.com has two groups. The developer group has close to 3000 messages going back over a year to before they released thier product. Most of it is just support stuff, but there were some really good disucssions as well... > Fill us in! ;-) > > Where can we find this? > > Travis > > ---- Original Message ---- > From: Andy Lewis <aj...@as...> > Sent: 2002-05-28 > To: obj...@li... > Subject: Re: AW: [Objectbridge-jdo-dev] StateManager > > I'm not sure if this would be considered "bad form", but there are two > newsgroups pulbicly available from the Kodo JDO folks that are probably > archived somewhere. This was where they went through all of thier pre- > release, beta, and inital release support, along with a lot of > discussions about compliance details. > > Might make an interesting resource for some topics... > >> 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 >>> >> >> _______________________________________________________________ >> >> 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 > > > "The heights of genius are only measurable by the depths of stupidity." > > > > > _______________________________________________________________ > > 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 "The heights of genius are only measurable by the depths of stupidity." |
From: <tr...@th...> - 2002-05-28 22:40:11
|
Fill us in! ;-) Where can we find this? Travis ---- Original Message ---- From: Andy Lewis <aj...@as...> Sent: 2002-05-28 To: obj...@li... Subject: Re: AW: [Objectbridge-jdo-dev] StateManager I'm not sure if this would be considered "bad form", but there are two newsgroups pulbicly available from the Kodo JDO folks that are probably archived somewhere. This was where they went through all of thier pre- release, beta, and inital release support, along with a lot of discussions about compliance details. Might make an interesting resource for some topics... > 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 >> > > _______________________________________________________________ > > 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 "The heights of genius are only measurable by the depths of stupidity." |
From: <tr...@th...> - 2002-05-28 22:35:33
|
You may want to check out www.crossdb.com, another project I am involved in for writing database independent queries. It would be quite simple to do what we're talking about using crossdb. Travis ---- Original Message ---- From: Thomas Mahler <tho...@ho...> Sent: 2002-05-28 To: obj...@li... Subject: Re: [Objectbridge-jdo-dev] Object store (automated database creation) Hi Travis tr...@th... wrote: > 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? > Yes, That's cool idea.In certain production environments it won't be allowed to create tables on the fly (e.g. in my company all database tables you want to be created must be qa'ed by the DBA team...). But for all others this kind of thing could be quite helpful. I'm planing to have a whole toolset for metadata operations in OJB 2.0. This toolset will allow to - forward engineer java classes to Metadata and DDL (possibly with on the fly generation in the db) With this kind of tool it will be easy to build for instance a persistent XML DOM implementation as one would need in an XML data server... (this is one of the demos that's on my todo list for a very long time...) - reverse engineering from relational database to Java classes and Metadata - a Mapping workbench to allow manual mapping from Java classes to RDBMS tables. Of course it must also be possible to parse *.jdo files to Ojb Metadata and to generat *.jdo files from the MetaData layer. This can be done by extending the RepositoryPersistor. So there will be a lot of interesting things to do for OJB 2.0 ... cheers, 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 > > > > > _______________________________________________________________ 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: Andy L. <aj...@as...> - 2002-05-28 21:34:17
|
I'm not sure if this would be considered "bad form", but there are two newsgroups pulbicly available from the Kodo JDO folks that are probably archived somewhere. This was where they went through all of thier pre- release, beta, and inital release support, along with a lot of discussions about compliance details. Might make an interesting resource for some topics... > 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 >> > > _______________________________________________________________ > > 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 "The heights of genius are only measurable by the depths of stupidity." |
From: Andy L. <aj...@as...> - 2002-05-28 21:33:24
|
I think it is simply required to meet the criteria for an EJB key - ifor example, it must be serializable. > 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 >> >> >> 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 >> >> _______________________________________________________________ >> >> 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 "The heights of genius are only measurable by the depths of stupidity." |
From: Thomas M. <tho...@ho...> - 2002-05-28 21:12:21
|
hi, Andy Lewis wrote: <snip> > I'm still missing something here - it sounds like everything can be handled > in the JDO file, but that it simply becomes very verbose. > > Is that accurate? > I think you are right: This JDO file must keep all information, currently in the repository.xml file. As we are bound to the JDO extension mechanism this JDO file won't be as concise as a repository.xml. Thomas |
From: Andy L. <aj...@as...> - 2002-05-28 21:00:37
|
<snip/> > > 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! > >> What about >> the option of maintaining a separate file? >> > > That's my original suggestion. Maybe it was not that bad ? > > Thomas > > <snip/> I'm still missing something here - it sounds like everything can be handled in the JDO file, but that it simply becomes very verbose. Is that accurate? "The heights of genius are only measurable by the depths of stupidity." |
From: Thomas M. <tho...@ho...> - 2002-05-28 20:41:40
|
Hi Travis tr...@th... wrote: > 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? > Yes, That's cool idea.In certain production environments it won't be allowed to create tables on the fly (e.g. in my company all database tables you want to be created must be qa'ed by the DBA team...). But for all others this kind of thing could be quite helpful. I'm planing to have a whole toolset for metadata operations in OJB 2.0. This toolset will allow to - forward engineer java classes to Metadata and DDL (possibly with on the fly generation in the db) With this kind of tool it will be easy to build for instance a persistent XML DOM implementation as one would need in an XML data server... (this is one of the demos that's on my todo list for a very long time...) - reverse engineering from relational database to Java classes and Metadata - a Mapping workbench to allow manual mapping from Java classes to RDBMS tables. Of course it must also be possible to parse *.jdo files to Ojb Metadata and to generat *.jdo files from the MetaData layer. This can be done by extending the RepositoryPersistor. So there will be a lot of interesting things to do for OJB 2.0 ... cheers, 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 > > > > > |