objectbridge-jdo-dev Mailing List for ObJectRelationalBridge (Page 6)
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-14 04:39:22
|
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?
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?
Travis Reeder
Chief Software Architect
www.ThinkVirtual.com
|
|
From: Thomas M. <tho...@ho...> - 2002-05-12 15:48:53
|
Hi Sebastian, Sebastian Kanthak wrote: > Hi, > > I'm strongly interested in (working on) open-source jdo implementations and > noticed your project. I took a first look at ojb and wondered about the > following problem: > > If I understood the source code correctly, ojb uses reflection to read/write > member variables of persistence capable classes. OJB provides an Interface PersistentField to encapsulate the field access. Currently we provide two implementations, one based on reflection, one based on Javabeans property access. The used implementation is configured in OJB.properties. > On the other hand, jdo uses > an explicit interface (PersistenceCapable) implemented automatically by the > enhancer. My question is: Do you want to keep the "reflection-based" approach > for your jdo implementation? No we will stick 100% to the JDO spec! > This would probably lead to problems when > working with enhanced classes, as they expect a state-manager providing them > their fields via the the methods defined in the PersistenceCapable (and > StateManager) interfaces. However, the spec requires binary compatibility > between jdo implementations, e.g. it has to work with classes enhanced by the > reference enhancer. > That's why we have to stick to the spec! Otherwise we won't be JDO compliant and won't be able to work with classes enhanced by different tools. > Of course there are other tradeoffs between the reflection-based approach and > an enhancer-based approach: > > - Reflection should be somewhat slower than enhanced classes Right its also slower than the Javabeans compliant approach. > - Enhancement is another step in the build process and can make debugging > difficult > - Enhancement does not require Proxy-generated classes as stubs to load > objects from the datastore on-demand. Yes, all those infrastructure-stuff can be hidden by the enhancement process. > > So, to summarize my question: Do you want to keep the reflectio-based > approach No! (In fact OJB is already open in this respect) > or is a solution possible, where data read from the data store is > passed to a StateManager instead of directly into the PersistenceCapable > instance? > Sure! cu, Thomas > ciao Sebastian > > |
|
From: Sebastian K. <seb...@mu...> - 2002-05-12 14:41:41
|
On Sunday 12 May 2002 16:00, Christian Sell wrote: > > - Enhancement is another step in the build process and can make debugging > > difficult > > slightly off-topic, but this is one of the statements that one always gets > to hear when the disadvantages of enhancement are discussed. Yet I do not > understand why this should be so. The Java Bytecode and debugger interface > are all well documented, so it should be rather trivial to make the > enhanced bytecode completely transparent with regard to debugging. well, of course, the enhancer has to take care, that line-information isn't lost, but I guess, that some debuggers have problems when the command to be executed is a method call (for example to jdoGetXXX), but the source code is a "localVariable = this.persistentMemberVariable". If you now give the normal "step" command the debugger will step into a method where he does not expect one and that does not exist in the source code. Perhaps "simple debuggers", that only rely on the line-numbers work better here, that debuggers that analyze the source-code. However, the jdo spec seems to make pretty clear, that debugging should not be a big problem, I only wanted to mention it. ciao Sebastian -- Sebastian Kanthak | seb...@mu... |
|
From: Christian S. <chr...@ne...> - 2002-05-12 14:01:31
|
> - Enhancement is another step in the build process and can make debugging > difficult slightly off-topic, but this is one of the statements that one always gets to hear when the disadvantages of enhancement are discussed. Yet I do not understand why this should be so. The Java Bytecode and debugger interface are all well documented, so it should be rather trivial to make the enhanced bytecode completely transparent with regard to debugging. regards, Christian |
|
From: Sebastian K. <seb...@mu...> - 2002-05-12 12:20:54
|
Hi, I'm strongly interested in (working on) open-source jdo implementations and noticed your project. I took a first look at ojb and wondered about the following problem: If I understood the source code correctly, ojb uses reflection to read/write member variables of persistence capable classes. On the other hand, jdo uses an explicit interface (PersistenceCapable) implemented automatically by the enhancer. My question is: Do you want to keep the "reflection-based" approach for your jdo implementation? This would probably lead to problems when working with enhanced classes, as they expect a state-manager providing them their fields via the the methods defined in the PersistenceCapable (and StateManager) interfaces. However, the spec requires binary compatibility between jdo implementations, e.g. it has to work with classes enhanced by the reference enhancer. Of course there are other tradeoffs between the reflection-based approach and an enhancer-based approach: - Reflection should be somewhat slower than enhanced classes - Enhancement is another step in the build process and can make debugging difficult - Enhancement does not require Proxy-generated classes as stubs to load objects from the datastore on-demand. So, to summarize my question: Do you want to keep the reflectio-based approach or is a solution possible, where data read from the data store is passed to a StateManager instead of directly into the PersistenceCapable instance? ciao Sebastian -- Sebastian Kanthak | seb...@mu... |
|
From: <tr...@th...> - 2002-05-10 17:30:05
|
I started a separate project on sourceforge at: http://johndoe.sourceforge.net Just a holding ground for the code because I don't want to wait to start using JDO. The CVS has the tutorial3 example using JDO. For the most part I just extended the matching OJB classes and made them implement the JDO interfaces so performance/response should be almost identical. Give it a try and let me know how it goes. I've started to try it with other applications and it seems to work fine outside the tutorial app too. Travis ---- Original Message ---- From: Bruce Buttles <bru...@ho...> Sent: 2002-05-10 To: tr...@th... Subject: Re: [Objectbridge-jdo-dev] JDO Tutorial application Hey that ROCKS! I can't wait to hear more ... Have you had a chance to look at perf/response time between the two? -Bruce ----Original Message Follows---- From: tr...@th... To: obj...@so... Subject: [Objectbridge-jdo-dev] JDO Tutorial application Date: Thu, 9 May 2002 14:32:03 -0600 (MDT) I have made a JDO layer for OJB that runs the tutorial application using only the JDO API. And I've found that the OJB PersistenceBroker (not odmg) is almost dead on to the JDO spec at least for the basics. For example in UCEditProduct (commented lines were from original). broker is created earlier and is a PersistenceManager as in JDO spec. broker.makePersistent(toBeEdited); Transaction tx = null; // 3. open transaction tx = broker.currentTransaction(); tx.begin(); // 6. now ask broker to store the edited object //broker.store(toBeEdited); // 7. commit transaction //broker.commitTransaction(); tx.commit(); Travis _______________________________________________________________ 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 _________________________________________________________________ Join the world?s largest e-mail service with MSN Hotmail. http://www.hotmail.com |
|
From: <tr...@th...> - 2002-05-09 20:37:31
|
I have made a JDO layer for OJB that runs the tutorial application using only the JDO API. And I've found that the OJB PersistenceBroker (not odmg) is almost dead on to the JDO spec at least for the basics.
For example in UCEditProduct (commented lines were from original).
broker is created earlier and is a PersistenceManager as in JDO spec.
broker.makePersistent(toBeEdited);
Transaction tx = null;
// 3. open transaction
tx = broker.currentTransaction();
tx.begin();
// 6. now ask broker to store the edited object
//broker.store(toBeEdited);
// 7. commit transaction
//broker.commitTransaction();
tx.commit();
Travis
|
|
From: Juozas B. <ba...@ce...> - 2002-05-08 18:21:42
|
Yes, it is like:" <extension vendor-name=sunw key=element-inverse value=dept/>" ----- Original Message ----- From: <tr...@th...> To: <obj...@so...> Sent: Wednesday, May 08, 2002 6:59 PM Subject: RE: Re: [Objectbridge-jdo-dev] JDO spec mapping to db tables > So that would remain vendor specific then? > > Travis > > ---- Original Message ---- > From: Stefan Ortmanns <Ste...@gm...> > Sent: 2002-05-08 > To: obj...@so... > Subject: Re: [Objectbridge-jdo-dev] JDO spec mapping to db tables > > > I can't seem to find any information on how JDO is supposed to map classes > > and class fields to tables and table columns. > > > > Anyone know the answer to this? > > > > The XML example in the spec: > > > > Hi , > > as far as i know , the Reference Implementation does not use a RDBMS or a > Table > structure to make the objects persistent. > The reference implementation uses a store on file base. > But should i err, please inform me. > As far as i know , the Meta Data for table mapping > are not specified by the JDO Spec. > > Regards, > Stefan > > -- > GMX - Die Kommunikationsplattform im Internet. > http://www.gmx.net > > > _______________________________________________________________ > > 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 > > > > _______________________________________________________________ > > 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-08 17:04:31
|
So that would remain vendor specific then?
Travis
---- Original Message ----
From: Stefan Ortmanns <Ste...@gm...>
Sent: 2002-05-08
To: obj...@so...
Subject: Re: [Objectbridge-jdo-dev] JDO spec mapping to db tables
> I can't seem to find any information on how JDO is supposed to map classes
> and class fields to tables and table columns.
>
> Anyone know the answer to this?
>
> The XML example in the spec:
>
Hi ,
as far as i know , the Reference Implementation does not use a RDBMS or a
Table
structure to make the objects persistent.
The reference implementation uses a store on file base.
But should i err, please inform me.
As far as i know , the Meta Data for table mapping
are not specified by the JDO Spec.
Regards,
Stefan
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
_______________________________________________________________
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: Stefan O. <Ste...@gm...> - 2002-05-08 16:45:27
|
> I can't seem to find any information on how JDO is supposed to map classes
> and class fields to tables and table columns.
>
> Anyone know the answer to this?
>
> The XML example in the spec:
>
Hi ,
as far as i know , the Reference Implementation does not use a RDBMS or a
Table
structure to make the objects persistent.
The reference implementation uses a store on file base.
But should i err, please inform me.
As far as i know , the Meta Data for table mapping
are not specified by the JDO Spec.
Regards,
Stefan
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
|
|
From: <tr...@th...> - 2002-05-08 16:19:06
|
I can't seem to find any information on how JDO is supposed to map classes = and class fields to tables and table columns. =20 Anyone know the answer to this? The XML example in the spec: <?xml version=3D=941.0=94 encoding=3D=94UTF-8=94?> <!DOCTYPE jdo SYSTEM =93jdo.dtd=94> <jdo> <package name=3D=94com.xyz.hr=94> <class name=3D=94Employee=94 identity-type=3D=94application=94 objectidclas= s=3D=94 EmployeeKey=94> <field name=3D=94name=94 primary-key=3D=94true=94> <extension vendor-name=3D=94sunw=94 key=3D=94index=94 value=3D=94btree=94/> </field> <field name=3D=94salary=94 default-fetch-group=3D=94true=94/> <field name=3D=94dept=94> <extension vendor-name=3D=94sunw=94 key=3D=94inverse=94 value=3D=94emps=94/= > </field> <field name=3D=94boss=94/> </class> <class name=3D=94Department=94 identity-type=3D=94application=94 objectidcl= ass=3D=94 DepartmentKey=94> <field name=3D=94name=94 primary-key=3D=94true=94/> <field name=3D=94emps=94> <collection element-type=3D=94Employee=94> <extension vendor-name=3D=94sunw=94 key=3D=94element-inverse=94 value=3D=94= dept=94/> </collection> </field> </class> </package> </jdo> Travis |
|
From: Travis R. <tr...@th...> - 2002-05-07 22:09:11
|
Looking at your work and it looks very good, i am wanting to build a new application using JDO so that I don't have to change it later, and have been hacking away at adding a layer to ojb. It seems that your original layer, ojb.broker (not odmg), fits the model the best so I've been going in that route. I'm finding some strange occurences though for example, the DescriptorRepository in PersistenceBrokerImpl throws NullPointerExceptions at strange times, like if you do a System.out.println with it. In the getCollectionByQuery and getObjectByIdentity, I'm getting nullpointexceptions on m_DescriptorRepository.getDescriptorFor. Any ideas? Travis |
|
From: Mahler T. <tho...@it...> - 2002-05-03 11:38:43
|
Hi Stefan, > -----Urspr=FCngliche Nachricht----- > Von: Stefan Ortmanns [mailto:Ste...@gm...] > Gesendet: Freitag, 3. Mai 2002 11:24 > An: Obj...@li... > Betreff: [Objectbridge-jdo-dev] OJB JDO Implementation >=20 >=20 > Hi, >=20 > i'm very interessted in JDO. > I've readed the (short) JDO Implementation concept for OJB. > I want to ask for the State of the OJB JDO Implementation. > If there is still help needed, i'm interessted in helping. >=20 Of course you are welcome to help! Currently we have not started coded. Most OJB developers are busy with bringing out OJB release 1.0 (planned for end of June!) Once we have some time, we can start on JDO coding... For the time beeing you should study the SUN JDO Rererence = implementation and the OJB ODMG Implementation, to learn how thins can be done for = OJB-JDO. If you have some time left, you might also try to start on a prototype! cheers, Thomas > Regards, > Stefan >=20 >=20 > --=20 > GMX - Die Kommunikationsplattform im Internet. > http://www.gmx.net >=20 >=20 > _______________________________________________________________ >=20 > Have big pipes? SourceForge.net is looking for download=20 > mirrors. We supply > the hardware. You get the recognition. Email Us:=20 > ban...@so... > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev >=20 |
|
From: Stefan O. <Ste...@gm...> - 2002-05-03 09:24:03
|
Hi,
i'm very interessted in JDO.
I've readed the (short) JDO Implementation concept for OJB.
I want to ask for the State of the OJB JDO Implementation.
If there is still help needed, i'm interessted in helping.
Regards,
Stefan
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
|
|
From: Joel S. <jo...@ik...> - 2002-04-18 17:34:33
|
> Code Modification
>
> We did not do code modification, but I had a play with the BCEL library
> and I think that that would be a candidate for use. There is (was?) a
> better library from IBM alphaworks that presents an API similar to
> reflection, but allowing modification of byte-code, but I think that was
> not under open source. The enhancement would need to be pluggable, to
> allow us to try out some different implementations.
I've looked at various open source bytecode manipulation APIs and
they're much the same.
I think BCEL will have the largest community and best support probably
(because it's apache) and so I think that would be the best choice.
> We used source-code modification and reflection, ie the jdoXXX calls
> were in a PersistenceCapableImpl superclass from which all our db
> classes descended,
This isn't possible. That would require multiple inheritance when the PC
already extends something else.
> and the ClassManagers used reflection to read the
> actual values. Classes encapsulated all fields with getXXX and setXXX
> methods and explicitly called jdoMarkDirty() methods on modification.
With the way the spec is set up, the state manager will know everything
(it knows more than the PC does itself!) so we won't need reflection
anywhere (that I know of).
> Having done this I can see why code modification is necessary - we had a
> few bugs when a method was added but the jdoMarkDirty() was not :-) I
> would suggest that an implementation should aim at hand-modified source
> and worry about code-modification in parallel.
Perhaps, though we have some work already done towards it--and it
appears there is a separate body that Andy knows of that we may be able
to use some code (including an enhancer) from.
Either way, code enhancement is not a big project because it's pretty
much spelled out in the spec and I'm not sure we want to deviate from
that because of compatibility requirements.
> HOLLOW state
>
> We did not implement the HOLLOW state, which made the code for 1-1
> relationships nasty. Every relationship getter required a
> jdoLoad("relationshipName") method to trigger loading of the appropriate
> object. I would say HOLLOW state is a must.
>
> Caching
>
> Our PersistenceManagerImpl maintained 2 caches - a memory sensitive
> cache like objectbridge, and a dirtyCache which maintained only objects
> marked as PERSISTENT_DIRTY, PERSISTENT_NEW or PERSISTENT_DELETED in a
> list. This meant that db checking was only the small number of changed
> objects. This is a great boon for the JDO.
>
> savepoint()
>
> As hinted above, we extended the pm to have a checkpoint() method, which
> proved extremely useful. This is less so now, as the spec has been
> modified to allow the user to call setRetainValues(true) so that objects
> are not made HOLLOW on commit. However there is still a problem
> potentially with objects that outlive a pm. For example, if you create
> an object and then want to cache it in a singleton, then changes to the
> object are not automatically persisted, unless the singleton makes a
> commit(). It then has to re-associate all objects with a new PM in order
> to record new changes to the objects. It was much simpler to have a PM
> associated with the singleton and call checkpoint() periodically. Note
> that this is on the TO-DO list of the 1.0 spec as savepoint().
I think I understand you. So you're talking outside of transactions?
> The new optional 'optimistic transactions' part of the spec is a good
> fit for this functionality too, and better in that it doesn't maintain a
> connection to the database for a long lived pm. This allows usage
> patterns like creating a PM and storing it in the session of a web
> transaction, and managing all interactions through this PM. We had to
> abandon this idea since our implementation maintained an open connection
> for each open PM, and we rapidly ran out of connections.
Does the spec require one connection per PM? I would think that would be
a bad thing. I would think the db connection pool should be separated
from the PM so the PM could just grab a connection when it needed one.
> Change logging
>
> One of the interesting things about our implementation was the
> changelog. Any change to the database was recorded by a Change object,
> that held the className, fieldNames and the old and new values of
> changed fields. The fieldName was used so that the Change object could
> be used to apply changes to a database with a different schema, or where
> the mapping had changed. This was used to synchronize our web database
> (MySQL) with our internal database (MS SQL Server). It worked extremely
> well, and I would heartily recomment this approach. It was implemented
> by having the PersistenceManagerFactory (nb, not the individual PMs)
> fire transactionCommitted events with a list of changes. This allows the
> maximum amount of flexibility in monitoring changes on the database. the
> changes were logged in an XML format for transfer.
Interesting.
> Queries
>
> The most we ever did with queries was to filter for objects. It was
> never necessary to use complex queries, since the relationships
> maintained by JDO allow you to navigate to the necessary object. I'm
> sure anyoune who has had to embed queries in code and debug them would
> agree that its easier to avoid it than work with it. So I don't think
> complex query support is essential for early versions.
>
> Having said that, over time it would be nice to support variants like
> OQL and EJBQL for the implementation, since this would allow an
> isql-like app that manipulates live object data. Now that would be a
> killer app.
>
> IMHO the implementation of querying should be aimed at two uses:
>
> 1. I have a collection of instances and I want to use a query construct
> to sort/filter them. So the filter must be applicable to a set of
> objects without hitting the database.
>
> 2. I want to fetch data from the database according to a filter. This is
> easily implemented by navigating an extent and using the same filter as
> in (1) above, but this is extremely inefficient to the point of being
> useless in large systems. Thus the system must be able to pass all or
> part of the query 'down the chain' to a lower level component that can
> use all or part of it to generate an SQL query. The full filter can then
> be applied to the smaller set of objects returned. This will be crucial
> for real world use.
Okay. As you suggested, I envision the querying engine to be one of the
later modules developed as it is rather complicated and because you can
have a very useful piece of software without it (see Ozone for example).
Thanks for your comments!
--
Joel Shellman
Comprehensive Internet Solutions -- Building business dreams.
[ web design | database | e-commerce | hosting | marketing ]
iKestrel, Inc. http://www.ikestrel.com/
|
|
From: Chris S. <sk...@us...> - 2002-04-17 13:04:18
|
Hi guys, I was pointed to this group by Thomas Mahler of the
objectbridge group.
I am interested in helping with the sparrow/objectbridge efforts to
implement JDO in open source. What follows is a description of what we
did, with some thoughts about the JDO spec as it currently stands, and
what I think is important to target.
I am moving between countries at the moment, and don't have permanent
Internet connection, so this is off the top of my head.
At my former employer we implemented a persistence mechanism based on
the JDO early drafts. It has been in use for over a year now on our
website, and coped well with a large amount of traffic (30,000 distinct
page views in a day, with heavy database access, running at a peak of
25+ pages per second). The library interfaces with a MySQL server on the
web site, and MS SQL Server on the internal side. Data is synchronized
in real time through the persistence libraries. I can vouch for the
suitability of the spec for real world use :-)
Code Modification
We did not do code modification, but I had a play with the BCEL library
and I think that that would be a candidate for use. There is (was?) a
better library from IBM alphaworks that presents an API similar to
reflection, but allowing modification of byte-code, but I think that was
not under open source. The enhancement would need to be pluggable, to
allow us to try out some different implementations.
We used source-code modification and reflection, ie the jdoXXX calls
were in a PersistenceCapableImpl superclass from which all our db
classes descended, and the ClassManagers used reflection to read the
actual values. Classes encapsulated all fields with getXXX and setXXX
methods and explicitly called jdoMarkDirty() methods on modification.
Having done this I can see why code modification is necessary - we had a
few bugs when a method was added but the jdoMarkDirty() was not :-) I
would suggest that an implementation should aim at hand-modified source
and worry about code-modification in parallel.
HOLLOW state
We did not implement the HOLLOW state, which made the code for 1-1
relationships nasty. Every relationship getter required a
jdoLoad("relationshipName") method to trigger loading of the appropriate
object. I would say HOLLOW state is a must.
Caching
Our PersistenceManagerImpl maintained 2 caches - a memory sensitive
cache like objectbridge, and a dirtyCache which maintained only objects
marked as PERSISTENT_DIRTY, PERSISTENT_NEW or PERSISTENT_DELETED in a
list. This meant that db checking was only the small number of changed
objects. This is a great boon for the JDO.
savepoint()
As hinted above, we extended the pm to have a checkpoint() method, which
proved extremely useful. This is less so now, as the spec has been
modified to allow the user to call setRetainValues(true) so that objects
are not made HOLLOW on commit. However there is still a problem
potentially with objects that outlive a pm. For example, if you create
an object and then want to cache it in a singleton, then changes to the
object are not automatically persisted, unless the singleton makes a
commit(). It then has to re-associate all objects with a new PM in order
to record new changes to the objects. It was much simpler to have a PM
associated with the singleton and call checkpoint() periodically. Note
that this is on the TO-DO list of the 1.0 spec as savepoint().
The new optional 'optimistic transactions' part of the spec is a good
fit for this functionality too, and better in that it doesn't maintain a
connection to the database for a long lived pm. This allows usage
patterns like creating a PM and storing it in the session of a web
transaction, and managing all interactions through this PM. We had to
abandon this idea since our implementation maintained an open connection
for each open PM, and we rapidly ran out of connections.
Change logging
One of the interesting things about our implementation was the
changelog. Any change to the database was recorded by a Change object,
that held the className, fieldNames and the old and new values of
changed fields. The fieldName was used so that the Change object could
be used to apply changes to a database with a different schema, or where
the mapping had changed. This was used to synchronize our web database
(MySQL) with our internal database (MS SQL Server). It worked extremely
well, and I would heartily recomment this approach. It was implemented
by having the PersistenceManagerFactory (nb, not the individual PMs)
fire transactionCommitted events with a list of changes. This allows the
maximum amount of flexibility in monitoring changes on the database. the
changes were logged in an XML format for transfer.
Queries
The most we ever did with queries was to filter for objects. It was
never necessary to use complex queries, since the relationships
maintained by JDO allow you to navigate to the necessary object. I'm
sure anyoune who has had to embed queries in code and debug them would
agree that its easier to avoid it than work with it. So I don't think
complex query support is essential for early versions.
Having said that, over time it would be nice to support variants like
OQL and EJBQL for the implementation, since this would allow an
isql-like app that manipulates live object data. Now that would be a
killer app.
IMHO the implementation of querying should be aimed at two uses:
1. I have a collection of instances and I want to use a query construct
to sort/filter them. So the filter must be applicable to a set of
objects without hitting the database.
2. I want to fetch data from the database according to a filter. This is
easily implemented by navigating an extent and using the same filter as
in (1) above, but this is extremely inefficient to the point of being
useless in large systems. Thus the system must be able to pass all or
part of the query 'down the chain' to a lower level component that can
use all or part of it to generate an SQL query. The full filter can then
be applied to the smaller set of objects returned. This will be crucial
for real world use.
|
|
From: Thomas M. <tho...@ho...> - 2002-04-16 18:25:04
|
Hi Chris, Chris Stevenson wrote: > I am interested in joining a move to JDO compliance for objectbridge. Great, every helping hand is welcome! > At my previous employer I implemented a persistence library based on the > JDO spec which has been in use for over a year now in a production > environment. Cool! So you did a full implementation with instance lifecycle, code enhancement etc.? > I have no restrictions on repeating that for this project. This would be a great help! > I was wondering what the status is? I have noticed that the jdo > interfaces are in CVS, but there is no other code in yet? > That's right. Most OJB developers are currently focussed on getting Version 1.0 finished till June! JDO is not in the 1.0 scope. Currently we are discussing design issues etc. We also have been discussing with the Sparrow project about a close collaboration. SParrow wants to provide a "JDO front end" with pluggable Store implementations. Their main focus are integration OODBMS backends. We will provide the O/R backend. (I assume you are familiar with SUNS's JDORI. The RI has a similar design. it consists of a slim JDO Implementation incl. Lifecycle with pluggable StoreManagers.) I think this is a solid approach. What do you think? How did your implementation work? You are most welcome to share your ideas, concepts and to contribute your code! thanks, Thomas > chris > > > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > |
|
From: Chris S. <zh...@ma...> - 2002-04-15 12:08:07
|
I am interested in joining a move to JDO compliance for objectbridge. At my previous employer I implemented a persistence library based on the JDO spec which has been in use for over a year now in a production environment. I have no restrictions on repeating that for this project. I was wondering what the status is? I have noticed that the jdo interfaces are in CVS, but there is no other code in yet? chris |
|
From: Thomas M. <tho...@ho...> - 2002-04-13 09:37:52
|
Hi Joel, Hi Andy, Joel Shellman wrote: > On Fri, 2002-04-12 at 06:48, Andy Lewis wrote: > >>Ok...so is this, as it appears to be, a cross-community consensus that: >> >>- Sparrow will focus on JDO with a pluggable architecture >>- ORB will focus on a clean, core O/R engine >> I agree ! >>Implying further that: >> >>- Both communities have a vested interest in getting the Sparrow JDO front >>end working on the ORB kernel >>- Each project will effectively "endorse" the other >>- People will be encouraged to contribute to both efforts when possible >>- Sparrow become the JDO interface to ORB >>- ORB becomes the "default" plug-in back end for Sparrow >> >>Tell me if I have asserted facts not in evidence here.... >> > I agree ! > Sounds accurate. If all is agreed, I will make appropriate changes to > the Sparrow summary verbage on Sourceforge to reflect the slight change > of focus, and we should probably carry out discussions of the JDO > architecture and store interface on the sparrow-devel discussion list. > > I will try to come up to speed on PersistenceBroker as soon as possible > and if it fits well for my current effort, I may go ahead and integrate > it with my current code as I think it may have things that would save me > work anyway. > just drop me a line if you have any questions. cu, Thomas > Thanks! > > -joel > > _______________________________________________ > Objectbridge-jdo-dev mailing list > Obj...@li... > https://lists.sourceforge.net/lists/listinfo/objectbridge-jdo-dev > > > > |
|
From: Joel S. <jo...@ik...> - 2002-04-12 16:50:19
|
On Fri, 2002-04-12 at 06:48, Andy Lewis wrote: > Ok...so is this, as it appears to be, a cross-community consensus that: > > - Sparrow will focus on JDO with a pluggable architecture > - ORB will focus on a clean, core O/R engine > > Implying further that: > > - Both communities have a vested interest in getting the Sparrow JDO front > end working on the ORB kernel > - Each project will effectively "endorse" the other > - People will be encouraged to contribute to both efforts when possible > - Sparrow become the JDO interface to ORB > - ORB becomes the "default" plug-in back end for Sparrow > > Tell me if I have asserted facts not in evidence here.... Sounds accurate. If all is agreed, I will make appropriate changes to the Sparrow summary verbage on Sourceforge to reflect the slight change of focus, and we should probably carry out discussions of the JDO architecture and store interface on the sparrow-devel discussion list. I will try to come up to speed on PersistenceBroker as soon as possible and if it fits well for my current effort, I may go ahead and integrate it with my current code as I think it may have things that would save me work anyway. Thanks! -joel |
|
From: Joel S. <jo...@ik...> - 2002-04-12 16:40:47
|
> > How does that sound? > > For me it's definitely OK! > > So when will you have finished #1? ;-) Er, umm, well... :) -joel |
|
From: Andy L. <aj...@as...> - 2002-04-12 13:48:51
|
Ok...so is this, as it appears to be, a cross-community consensus that: - Sparrow will focus on JDO with a pluggable architecture - ORB will focus on a clean, core O/R engine Implying further that: - Both communities have a vested interest in getting the Sparrow JDO front end working on the ORB kernel - Each project will effectively "endorse" the other - People will be encouraged to contribute to both efforts when possible - Sparrow become the JDO interface to ORB - ORB becomes the "default" plug-in back end for Sparrow Tell me if I have asserted facts not in evidence here.... > Hi Joel, Hi Andy, > >> I would like to second your suggestion that Sparrow do #1 >> because... #3 >> might not be part of the Sparrow project after all. For example, I >> mentioned Ozone. Sparrow could be the front JDO with pluggable stores >> architecture, and Ozone or other object databases could then do their >> own work to conform to that pluggable architecture. >> > excluding #3 from the Sparrow scope will be the best solution to get > Sparrow started as fast as possible. > >> Thus... let's call Sparrow the front end JDO architecture and if I >> decide to do a new optimized object storage for it (which I >> would really >> like to but don't know if I'll have time), that could be the third >> project. >> >> How does that sound? > > For me it's definitely OK! > > So when will you have finished #1? ;-) > > cu, > > Thomas > >> -- >> Joel Shellman >> Comprehensive Internet Solutions -- Building business dreams. >> [ web design | database | e-commerce | hosting | marketing ] >> iKestrel, Inc. http://www.ikestrel.com/ >> "The heights of genius are only measurable by the depths of stupidity." |
|
From: Mahler T. <tho...@it...> - 2002-04-12 08:14:42
|
Hi Joel, <ozone deficits> ACK ! <snip db4o> <snip> > > Sounds good... What would be the quickest way for me to digest your > PersistenceBroker API? > There is a tutorial on the PB API: http://objectbridge.sourceforge.net/tutorial1.html JavaDoc is here: http://objectbridge.sourceforge.net/api/ojb/broker/package-summary.html To get an impression how a JDO implementation could use PB Api internally you might have a look at the OJB ODMG Implementation. Interesting points to get started: - ojb.odmg.TransactionImpl Each transactionImpl holds a PB to do perform persistence Operations. - ojb.odmg.oql.OQLQueryImpl the execute() method is most interesting. is shows how OQL Strings are parsed into OJB query objects. Than a PB is used to perform the query - ojb.odmg.states.ModificationState and subclasses this is a part that I really like. This is the ODMG instance lifecyle. it combines State Pattern and command pattern. StatePattern is used to model the state transition between the lifecycle states. (My ODMG impl follows closely the JDO spec. The only required JDO state not present is the "Hollow" state) command pattern is used to perform appropiate operations on commit and rollback. cu, Thomas |
|
From: Mahler T. <tho...@it...> - 2002-04-12 07:49:01
|
Hi Joel, Hi Andy, > I would like to second your suggestion that Sparrow do #1 > because... #3 > might not be part of the Sparrow project after all. For example, I > mentioned Ozone. Sparrow could be the front JDO with pluggable stores > architecture, and Ozone or other object databases could then do their > own work to conform to that pluggable architecture. > excluding #3 from the Sparrow scope will be the best solution to get Sparrow started as fast as possible. > Thus... let's call Sparrow the front end JDO architecture and if I > decide to do a new optimized object storage for it (which I > would really > like to but don't know if I'll have time), that could be the third > project. > > How does that sound? For me it's definitely OK! So when will you have finished #1? ;-) cu, Thomas > -- > Joel Shellman > Comprehensive Internet Solutions -- Building business dreams. > [ web design | database | e-commerce | hosting | marketing ] > iKestrel, Inc. http://www.ikestrel.com/ > |
|
From: Andy L. <aj...@as...> - 2002-04-11 20:06:25
|
> I apologize for being quiet for a few days. "Real life" got a little > crazy. understood... > Agreed. And that will be a project goal--that "pluggable stores" will > be able to easily evolve separate of the front end JDO impl. I do want > to keep things open for optimizations though. There may be situations > where we specific stores might want to override certain classes or > something to make things extremely fast/optimized. This can be designed > in as we go along, though and is optional. > > I guess what I'm trying to say is an elegant modular architecture with > support for a "fasttrack" pipeline for optimized stores. > > Modularity is great... but especially for my vision of a JDO object > store, I would really like it to scream. absolutely... > Thus... let's call Sparrow the front end JDO architecture and if I > decide to do a new optimized object storage for it (which I would > really like to but don't know if I'll have time), that could be the > third project. > > How does that sound? sounds fine to me...and sort of invalidates some of the following parts of the thread.... "The heights of genius are only measurable by the depths of stupidity." |
