Prev: FireFox3 Too Much Recursion nsPlacesDBFlush 259
Next: Code and Creation 01324
From: luc peuvrier on 7 Feb 2010 20:03
On 1 fév, 22:41, Lew <no...(a)lewscanon.com> wrote:
> luc peuvrier wrote:
> > Hi Tom [sic],
>
> > I do not think reinvented JDO. If you like JDO and well know it I will
> > be happy you compare theJOAFIPand JDO facade.
>
> Shouldn't that be your job as the spammer for theJOAFIPproject, not tom's?
>
> Burden of proof is on you.  Il est votre devoir.
>
> --
> Lew

Well understood after your last message.
Luc
From: luc peuvrier on 7 Feb 2010 20:12
On 4 fév, 02:59, Jeff Higgins <oohigg...(a)yahoo.com> wrote:
> luc peuvrier wrote:
> >http://joafip.sourceforge.net/
> > can be see as a:
> > - an "intelligent" serialization: write only changes, read only object
> > needed
> > - manage more object than memory can contains
> > - an alternate persistence solution to relationnal database
>
> Very well presented. Thank you.

According exchanges with lew I have to put water in my wine on joafip
as an alternative to a database: Do not expect joafip provide all
available un famous persistence solutions, but may be sufficient and
practical in some cases.
From: Lew on 7 Feb 2010 20:33
luc peuvrier wrote:
> Lew insist I answer to you and not ask to you to compare.
> Joafip is not same as JDO. I am not a JDO expert, but I had a look on
> its description. About joafip:
> - do not make able to choose storage form, only in a file
> - do not have request language, not an pool of object, but an object
> graph storage.
> - persist any data-model ( some constraints )

You are giving very good feedback. Merci, Luc.

--
Lew
From: Tom Anderson on 8 Feb 2010 09:36
On Sun, 7 Feb 2010, luc peuvrier wrote:

> On 1 f?v, 19:30, luc peuvrier <lcp...(a)gmail.com> wrote:
>> On Feb 1, 1:30�am, Tom Anderson <t...(a)urchin.earth.li> wrote:
>>
>>> On Sun, 31 Jan 2010, luc peuvrier wrote:
>>>> http://joafip.sourceforge.net/
>>>> can be see as a:
>>>> - an "intelligent" serialization: write only changes, read only object
>>>> needed
>>>> - manage more object than memory can contains
>>>> - an alternate persistence solution to relationnal database
>>
>>> So you've basically reinvented JDO? That's cool, i always liked JDO.
>>
>> I do not think reinvented JDO. If you like JDO and well know it I will
>> be happy you compare theJOAFIPand JDO facade.
>
> Lew insist I answer to you and not ask to you to compare.
> Joafip is not same as JDO. I am not a JDO expert, but I had a look on
> its description. About joafip:
>
> - do not make able to choose storage form, only in a file

True, but that fits with JDO. Different JDO implementations use different
kinds of storage - some use a RDBMS, some use files, some use something
else. Joafip is similar to a JDO implementation that only uses files.

> - do not have request language, not an pool of object, but an object
> graph storage.

True. JDO provides navigation as well - the examples you give for Joafip
could also be done with JDO (or JPA). But JDO and JPA also provide their
own languages. As it happens, IMHO most of the use of a persistence system
is navigational; you have a few well-known root objects (the ones bound to
a name in the session in Joafip), and then you navigate from there. Having
a query language is a nice extra, and in some cases is essential, but for
bread-and-butter storage applications, not required. Although of course,
once you have a query language, you do tend to use it more.

> - persist any data-model ( some constraints )

True. Same is true of JDO and JPA. With JPA, you need to add annotations
(or a configuration file) to say which attributes to persist, but with
JDO, you don't. With JDO, you need to apply bytecode enhancement, which
can be done at build-time, or at classingloading time, via an agent, which
i believe Joafip can also do.

So you see, Joafip looks very similar to a JDO implementation. I should
reiterate that this is a *good* thing, because JDO is a good standard!

tom

--
NTK now entirely filled with google links -- NTK
First  |  Prev  | 
Pages: 1 2 3 4 5 6 7
Prev: FireFox3 Too Much Recursion nsPlacesDBFlush 259
Next: Code and Creation 01324