You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Brian McCallister <mc...@forthillcompany.com> on 2004/02/23 15:34:05 UTC
JDO, was 1.0 final release
On Feb 23, 2004, at 6:22 AM, Antonio Gallardo wrote:
> Also what is the status of JDO? Are the test working here?
Antonio, as soon as 1.0 is out the door I am going to push hard to get
a native JDO implementation in asap.
I have heard from Matt privately and he wants to help out, but is more
or less insanely busy with work. I haven't heard anything from Raghu on
the list in a while, and I don't know Oleg's views re JDO. I believe
they have done most of the OTM work to date (which is awesome work,
btw).
I proposed a JDO-lite type implementation a while back -- but am not
sure how ideal that would be if it draws effort away from work on a
fully compliant JDO implementation (bytecode enhanced and casts to
PersistenceCapable allowed -- which we don't need to have a fully
working client api with everything except the cast).
http://marc.theaimsgroup.com/?t=107686918900001&r=1&w=2
What *are* people's thoughts on this? I heard support for the JDO-lite,
but putting effort into JDO-lite instead of JDO is a serious question.
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by "Robert S. Sfeir" <ro...@codepuccino.com>.
Brian McCallister wrote:
>
> On Feb 23, 2004, at 1:40 PM, Robert S. Sfeir wrote:
>
>> I know I can't vote, however my opinion is that if any of those are
>> good solid impls, it would gain OJB a lot of clout to integrate with
>> them.
>
>
> No vote needed! Just asking opinions and laying plans -- yours is much
> appreciated!
You're welcome :-)
R
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by Brian McCallister <mc...@forthillcompany.com>.
On Feb 23, 2004, at 1:40 PM, Robert S. Sfeir wrote:
> I know I can't vote, however my opinion is that if any of those are
> good solid impls, it would gain OJB a lot of clout to integrate with
> them.
No vote needed! Just asking opinions and laying plans -- yours is much
appreciated!
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by "Robert S. Sfeir" <ro...@codepuccino.com>.
Thomas Dudziak wrote:
>On Mon, 23 Feb 2004, Brian McCallister wrote:
>
>
>
>>What *are* people's thoughts on this? I heard support for the JDO-lite,
>>but putting effort into JDO-lite instead of JDO is a serious question.
>>
>>
>
>I would vote for a complete implementation of JDO, but I wonder whether
>there is need for YAOSJI (yet another open source JDO implementation).
>There at least four that I know of:
>
>http://jpox.sourceforge.net/
>http://xorm.sourceforge.net/
>http://speedo.objectweb.org/
>http://tjdo.sourceforge.net/
>
>Wouldn't it be more useful to approach one of them and propose an
>adaptation of their framework so that it uses OJB (AFAIK tjdo has an
>Apache License which would ease things) ?
>
>
>
I know I can't vote, however my opinion is that if any of those are good
solid impls, it would gain OJB a lot of clout to integrate with them.
R
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO (and OTM additions) (and maybe a PB addition)
Posted by Brian McCallister <mc...@forthillcompany.com>.
On Mar 26, 2004, at 1:23 PM, Thomas Mahler wrote:
> I'm not absolutely sure about 1). Maybe it could be implemented as a
> specific FieldAccess strategy on the PB level.
That is exactly what I want to do, sorry it wasn't clear =)
> But I see at least 2) and 3) above the PB layer (presumably on the OTM
> layer).
> Why to you think that those should be handled on the PB level?
Adding the interface at the PB level would be solely be because of the
PB level FieldAccess strategy. It could be purely in the o.a.ojb.jdo
namespace if we wanted -- just didn't know if we wanted to provide
bytecode-enhanced optimizations as an option in general (no dependency
on the javax.jdo namespace).
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO (and OTM additions) (and maybe a PB addition)
Posted by Thomas Mahler <th...@web.de>.
Hi Brian,
I agree with you that all three points are necessary to get a working
JDO implementation.
But I see at least 2) and 3) above the PB layer (presumably on the OTM
layer).
Why to you think that those should be handled on the PB level?
I'm not absolutely sure about 1). Maybe it could be implemented as a
specific FieldAccess strategy on the PB level.
cheers,
thomas
Brian McCallister wrote:
> Have been reading more JDO spec stuff and while I dislike how much it
> specifies still -- their heart is definitely in the right place.
>
> Some proposals in regard to approaching a JDO api and relations to the
> rest of OJB:
>
> 1) Add a FieldAccessor that talks to PersistenceCapable (PC) instance,
> or that talks to the interface proposed in (3)
>
> 2) Add a swizzling strategy and EditingContext which don't use copies,
> but direct flag fields as dirty etc via the PC object. This allows much
> faster determining of what needs to be updated on an OTM tx commit, and
> requires a lot less memory as clones of persistent fields don't need to
> be kept around in the editing context.
>
> 3) Provide an o.a.o.[broker|otm].??? level interface to provide access
> to bytecode enhanced classes' fields etc in order to provide the
> improved efficiency outside of just JDO (ODMG on OTM etc).
>
> -Brian
>
> On Feb 24, 2004, at 9:28 AM, Brian McCallister wrote:
>
>> On Feb 24, 2004, at 2:17 AM, Thomas Mahler wrote:
>>
>>> I'm also voting for a full implementation. But a "Lite"
>>> implementation could be a start.
>>
>>
>> I like the JDO-lite, personally, as I think most of the JDO SPI is
>> terrible -- but that is just me believing a spec should declare a
>> client API and not try to tell you how to implement it ;-) I recognize
>> the value in a full implementation though =)
>>
>> I am willing to be that if we wanted to we could make an
>> implementation which supports both methods -- you can use the SPI if
>> you feel like it, but if you don't we don't. The SPI interfaces would
>> simply be a facade over calls back into the OTM state tracking, and
>> the real work from the client API would not even use the SPI
>> implementation.
>>
>>>> There at least four that I know of:
>>>> http://jpox.sourceforge.net/
>>>> http://xorm.sourceforge.net/
>>>> http://speedo.objectweb.org/
>>>> http://tjdo.sourceforge.net/
>>
>>
>> JPox and TJDO have compatible licenses, Speedo and JPox don't have
>> compatible licenses.
>>
>> I nosed through the TJDO source last night and it is mostly clean
>> looking, but it pretty much wraps database transactions directly. In
>> theory they have the most to gain from working together as the
>> mapping system is quite weak (schema generation only -- no mapping to
>> existing schema). It looks pretty monolithic, however.
>>
>> Haven't looked at JPox yet.
>>
>> -Brian
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
JDO (and OTM additions) (and maybe a PB addition)
Posted by Brian McCallister <mc...@forthillcompany.com>.
Have been reading more JDO spec stuff and while I dislike how much it
specifies still -- their heart is definitely in the right place.
Some proposals in regard to approaching a JDO api and relations to the
rest of OJB:
1) Add a FieldAccessor that talks to PersistenceCapable (PC) instance,
or that talks to the interface proposed in (3)
2) Add a swizzling strategy and EditingContext which don't use copies,
but direct flag fields as dirty etc via the PC object. This allows much
faster determining of what needs to be updated on an OTM tx commit, and
requires a lot less memory as clones of persistent fields don't need to
be kept around in the editing context.
3) Provide an o.a.o.[broker|otm].??? level interface to provide access
to bytecode enhanced classes' fields etc in order to provide the
improved efficiency outside of just JDO (ODMG on OTM etc).
-Brian
On Feb 24, 2004, at 9:28 AM, Brian McCallister wrote:
> On Feb 24, 2004, at 2:17 AM, Thomas Mahler wrote:
>
>> I'm also voting for a full implementation. But a "Lite"
>> implementation could be a start.
>
> I like the JDO-lite, personally, as I think most of the JDO SPI is
> terrible -- but that is just me believing a spec should declare a
> client API and not try to tell you how to implement it ;-) I recognize
> the value in a full implementation though =)
>
> I am willing to be that if we wanted to we could make an
> implementation which supports both methods -- you can use the SPI if
> you feel like it, but if you don't we don't. The SPI interfaces would
> simply be a facade over calls back into the OTM state tracking, and
> the real work from the client API would not even use the SPI
> implementation.
>
>>> There at least four that I know of:
>>> http://jpox.sourceforge.net/
>>> http://xorm.sourceforge.net/
>>> http://speedo.objectweb.org/
>>> http://tjdo.sourceforge.net/
>
> JPox and TJDO have compatible licenses, Speedo and JPox don't have
> compatible licenses.
>
> I nosed through the TJDO source last night and it is mostly clean
> looking, but it pretty much wraps database transactions directly. In
> theory they have the most to gain from working together as the
> mapping system is quite weak (schema generation only -- no mapping to
> existing schema). It looks pretty monolithic, however.
>
> Haven't looked at JPox yet.
>
> -Brian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by Brian McCallister <mc...@forthillcompany.com>.
On Feb 24, 2004, at 2:17 AM, Thomas Mahler wrote:
> I'm also voting for a full implementation. But a "Lite" implementation
> could be a start.
I like the JDO-lite, personally, as I think most of the JDO SPI is
terrible -- but that is just me believing a spec should declare a
client API and not try to tell you how to implement it ;-) I recognize
the value in a full implementation though =)
I am willing to be that if we wanted to we could make an implementation
which supports both methods -- you can use the SPI if you feel like it,
but if you don't we don't. The SPI interfaces would simply be a facade
over calls back into the OTM state tracking, and the real work from the
client API would not even use the SPI implementation.
>> There at least four that I know of:
>> http://jpox.sourceforge.net/
>> http://xorm.sourceforge.net/
>> http://speedo.objectweb.org/
>> http://tjdo.sourceforge.net/
JPox and TJDO have compatible licenses, Speedo and JPox don't have
compatible licenses.
I nosed through the TJDO source last night and it is mostly clean
looking, but it pretty much wraps database transactions directly. In
theory they have the most to gain from working together as the mapping
system is quite weak (schema generation only -- no mapping to existing
schema). It looks pretty monolithic, however.
Haven't looked at JPox yet.
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by Thomas Mahler <th...@web.de>.
Hi all,
Thomas Dudziak wrote:
> On Mon, 23 Feb 2004, Brian McCallister wrote:
>
>
>>What *are* people's thoughts on this? I heard support for the JDO-lite,
>>but putting effort into JDO-lite instead of JDO is a serious question.
>
>
> I would vote for a complete implementation of JDO,
I'm also voting for a full implementation. But a "Lite" implementation
could be a start.
> but I wonder whether
> there is need for YAOSJI (yet another open source JDO implementation).
I generally agree with you. That's the way my JDORI plugin works. It's a
very clean separation of concerns.
> There at least four that I know of:
>
> http://jpox.sourceforge.net/
> http://xorm.sourceforge.net/
> http://speedo.objectweb.org/
> http://tjdo.sourceforge.net/
>
> Wouldn't it be more useful to approach one of them and propose an
> adaptation of their framework so that it uses OJB (AFAIK tjdo has an
> Apache License which would ease things) ?
I digged into some of those tool sime time ago, to see if there was a
chance of integration.
As of now I did not find a tool that would integrate easily with OJB.
- most tools don't have a clear separation beetwen object transaction
layer and o/r mapping engine. so integration won't be as easy as with
the JDORI.
- some of them provide limited functionality and are not JDO compliant
(and can't be made so without major redesign)
- I found some problematic source code which looked like verbatim copies
from the JDORI, which would cause us a lot of problems...
If there was an easy way, I'd be happy to go it!
cheers,
Thomas
>
> Just my 2ct ;-)
>
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by Antonio Gallardo <ag...@agssa.net>.
Brian McCallister dijo:
>
> On Feb 23, 2004, at 4:29 PM, Antonio Gallardo wrote:
>
>> My proposal is to review both 4:
>>
>> http://jpox.sourceforge.net/
>> http://xorm.sourceforge.net/
>> http://speedo.objectweb.org/
>> http://tjdo.sourceforge.net/
>>
>> Bases for selection:
>>
>> 1-Compatible AS License.
>> 2-level of implementation,
>> 3-Quality of code.
>> 4-others....
>
> <snip />
>
> 5-Ability to integrate -- some may be rather intimately tied to their
> O/R mapping technique.
>
> I am all for evaluating them and seeing if any are flexible enough to
> do this -- you willing to help?
I am happy for your proposal. I thought we can build a matrix with all the
features and compare them:
Features | Candidate A | Candidate B ....
ASL Yes Yes
...
Maybe using OJB wiki (if it exists) will be fine to publish this matrix
based on our own analysis. That way, other developers not involved in this
work will be able to see the result and help us to choice the right
candidate.
WDYT?
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by Brian McCallister <mc...@forthillcompany.com>.
On Feb 23, 2004, at 4:29 PM, Antonio Gallardo wrote:
> My proposal is to review both 4:
>
> http://jpox.sourceforge.net/
> http://xorm.sourceforge.net/
> http://speedo.objectweb.org/
> http://tjdo.sourceforge.net/
>
> Bases for selection:
>
> 1-Compatible AS License.
> 2-level of implementation,
> 3-Quality of code.
> 4-others....
<snip />
5-Ability to integrate -- some may be rather intimately tied to their
O/R mapping technique.
I am all for evaluating them and seeing if any are flexible enough to
do this -- you willing to help?
The JISP thing is annoying, I have been following that too. It does
remind me of the absolutely critical importance of maintaining loose
coupling between components though -- something we need to make sure we
continue to do in OJB.
-Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by Antonio Gallardo <ag...@agssa.net>.
My proposal is to review both 4:
http://jpox.sourceforge.net/
http://xorm.sourceforge.net/
http://speedo.objectweb.org/
http://tjdo.sourceforge.net/
Bases for selection:
1-Compatible AS License.
2-level of implementation,
3-Quality of code.
4-others....
The choosed one MUST have an ASL 2.0 compatible license. To me the best
will be if we can send a formal invitation to project commiters to join
ASF and start a incubation of these project under the ASF umbrella or
(maybe) directly inside the OJB project.
Why? From current experiences in Cocoon (related to jisp - changed in
version 3.0 to GPL):
http://marc.theaimsgroup.com/?t=107727454700003&r=1&w=2
And others similars experiences, I have concerns of using third party
projects because they can change the licenses at any time and if the JDO
implementation will be a very important piece of OJB, then we cannot risk
this at all.
Long time ago I proposed too TJDO, but Thomas have some concerns about it.
Not sure if this is still valid.
WDYT?
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Mon, 23 Feb 2004, Jakob Braeuchi wrote:
> hi thomas,
>
> i assume that those jdo-implementations have their own or-mapper under the hood
> and i doubt that they are eager to change it.
Probably (I know that TJDO has), but my belief is that both projects would
gain much:
* The jdo impl would get a solid and active db abstraction layer that
has transactions, works in clustered and managed environments, supports
all mayor databases (including oracle, db2, mssql) etc. etc. etc. In a
word, they wouldn't have to do the 'dirty' work of coding in sql for a
multitude of databases anymore, and at the same time gain new
developers that do this dirty work for them ;-) and also gain lots of new
functionality.
* The advantages for OJB are obvious, I guess: gaining a JDO
implementation, more users (and developers), more time to develop other
important stuff ;-)
I'm not talking about merging the two, but rather that after the 1.0, we
should perhaps first check whether any of the existing jdo impls could be
put on top of OJB without too much effort. If thats the case, we could
create such an integration prototype, and then propose it to the jdo impl
developers.
If not, well, then we can still develop our own jdo impl, right ?!
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by Jakob Braeuchi <jb...@gmx.ch>.
hi thomas,
i assume that those jdo-implementations have their own or-mapper under the hood
and i doubt that they are eager to change it.
but of course it would reasonable to put such a tool on top of ojb.
jakob
Thomas Dudziak wrote:
> On Mon, 23 Feb 2004, Brian McCallister wrote:
>
>
>>What *are* people's thoughts on this? I heard support for the JDO-lite,
>>but putting effort into JDO-lite instead of JDO is a serious question.
>
>
> I would vote for a complete implementation of JDO, but I wonder whether
> there is need for YAOSJI (yet another open source JDO implementation).
> There at least four that I know of:
>
> http://jpox.sourceforge.net/
> http://xorm.sourceforge.net/
> http://speedo.objectweb.org/
> http://tjdo.sourceforge.net/
>
> Wouldn't it be more useful to approach one of them and propose an
> adaptation of their framework so that it uses OJB (AFAIK tjdo has an
> Apache License which would ease things) ?
>
> Just my 2ct ;-)
>
> Tom
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: JDO, was 1.0 final release
Posted by Thomas Dudziak <to...@first.gmd.de>.
On Mon, 23 Feb 2004, Brian McCallister wrote:
> What *are* people's thoughts on this? I heard support for the JDO-lite,
> but putting effort into JDO-lite instead of JDO is a serious question.
I would vote for a complete implementation of JDO, but I wonder whether
there is need for YAOSJI (yet another open source JDO implementation).
There at least four that I know of:
http://jpox.sourceforge.net/
http://xorm.sourceforge.net/
http://speedo.objectweb.org/
http://tjdo.sourceforge.net/
Wouldn't it be more useful to approach one of them and propose an
adaptation of their framework so that it uses OJB (AFAIK tjdo has an
Apache License which would ease things) ?
Just my 2ct ;-)
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org