object relational database versus "inteligent" serialization

what do you think of
http://joafip.sourceforge.net/database/dbvsjoafip.html

I created joafip to manage more objects than memory can contains.
I can also be use to persist data model.
There is no query language, all is done using object navigation:
relations between class are coded in the classes.

On 2/7/2010 5:37 AM, luc peuvrier wrote:
> what do you think of
> http://joafip.sourceforge.net/database/dbvsjoafip.html
>
> I created joafip to manage more objects than memory can contains.
> I can also be use to persist data model.
> There is no query language, all is done using object navigation:
> relations between class are coded in the classes.

I get suspicious of anyone's code when the examples, such as the one
that leaps out at one from your link, contain major flaws from both a
coding and a pedagogical perspective. Your "item entity" example has a
constructor that calls 'super()' although the type descends directly
from 'Object' and 'super()' is called regardless. It uses 'float' to
represent a monetary amount. One might argue that it's "just" an
example, but that lack of attention to detail in the visible example
makes one worry whether you pay enough attention in the library code.

The far more serious flaws with the joafip library are that it recreates
the ancient network database model, where all the data relations are
predefined, that it imposes a lot of data-storage-aware code on core
logic that should be at least largely unaware of that aspect, that it
doesn't support any kind of ad hoc query mechanism that I can see, and
that it doesn't do any better at supporting an object model than
existing, robust, flexible solutions like every JPA implementation.

I've been working with databases, including both relational and
network-model systems, for nigh thirty years, and attempts to create
"object-oriented" data systems since "object-oriented" became a
buzzword. None of the OODBs or ORMs were worth a damn until Hibernate,
and since then, JPA rolled out. Now you come along, re-inventing the
wheel but ignoring things like suspension, springs, shock absorbers,
bearing grease, ...

It is obvious that a lot of work went into it, and within the severe
limitations of its programming model it seems rather complete. It's
just that I can write cleaner code, with more robust data interaction
and safety, and more convenient management of the underlying data
persistence, with more flexibility going forward, and the comfort of
knowing there's a large support framework, and I will bet dollars to
doughnuts far better performance especially under heavy or heavily
concurrent load, by going with a JPA solution like Hibernate,
TopLink/EclipseLink or OpenJPA.

Feel free to answer point by point with substantiable arguments.

--
Lew

On 07-02-2010 05:37, luc peuvrier wrote:
> what do you think of
> http://joafip.sourceforge.net/database/dbvsjoafip.html

I think the author is spamming to much in this group ....

Arne

On Feb 7, 11:01*pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
> On 07-02-2010 05:37, luc peuvrier wrote:
>
> > what do you think of
> >http://joafip.sourceforge.net/database/dbvsjoafip.html
>
> I think the author is spamming to much in this group ....
>
> Arne

May be announce joafip twice is two much.
I made an error the second announce was for comp.*lang.*java.*
databases
really sorry.
Luc

On Sun, 7 Feb 2010, Lew wrote:

> I've been working with databases, including both relational and
> network-model systems, for nigh thirty years, and attempts to create
> "object-oriented" data systems since "object-oriented" became a
> buzzword. None of the OODBs or ORMs were worth a damn until Hibernate,
> and since then, JPA rolled out.

Did you ever use GemStone/J? I haven't, but it's been going since the
bronze age, and has a good reputation.

tom

--
Dreams are not covered by any laws. They can be about anything. --
Cmdr Zorg

On Sun, 7 Feb 2010, Lew wrote:

> Tom Anderson challenged you to show how your project differs from JDO,
> the failed predecessor to JPA.

I didn't actually do that - i observed that it was the same. I wasn't
expecting the OP to disagree!

I wouldn't describe JDO as failed, either. It was a technical success, but
just a commercial failure, IMHO because there's so much inertia around
RDBMSs.

Nonetheless, i stand by my assertion that joafip is providing the same
service as a JDO implementation, which i think is the point you were
making use of here.

> Now you're back again, starting an entirely new thread on the exact same
> topic, and somehow I suspect you will once again refuse to engage
> directly in the challenge of showing why we should pay any attention
> whatsoever.

Maybe we should set him up with that guy who's reinvented CORBA, and isn't
interested in discussing the fact either. Between them, they've reinvented
a good chunk of the J2EE stack; we just need someone to reinvent servlets
and we've got the whole shooting match.

tom

--
Dreams are not covered by any laws. They can be about anything. --
Cmdr Zorg

On Feb 7, 6:00*pm, Lew <l...@lewscanon.com> wrote:
> On 2/7/2010 5:37 AM, luc peuvrier wrote:
>
> > what do you think of
> >http://joafip.sourceforge.net/database/dbvsjoafip.html
>
> > I created joafip to manage more objects than memory can contains.
> > I can also be use to persist data model.
> > There is no query language, all is done using object navigation:
> > relations between class are coded in the classes.
>
> I get suspicious of anyone's code when the examples, such as the one
> that leaps out at one from your link, contain major flaws from both a
> coding and a pedagogical perspective. *Your "item entity" example has a
> constructor that calls 'super()' although the type descends directly
> from 'Object' and 'super()' is called regardless. *

Java good practise say to call super, and PMD I use warning if missing

>It uses 'float' to
> represent a monetary amount. *One might argue that it's "just" an
> example, but that lack of attention to detail in the visible example
> makes one worry whether you pay enough attention in the library code.

Logic ! If I use a float for a monetary amount, who can imagine I can
write a quality code !

just between us, after 30 years of programming I have never handled
monetary data: surprise, right?

I am really happy to learn than float is not proper.

>
> The far more serious flaws with the joafip library are that it recreates
> the ancient network database model, where all the data relations are
> predefined,

Yes,but: relations between object are coded in class, a fixed data
model.
I do not know that serialize this fixed data model is the ancient
network database model...

> that it imposes a lot of data-storage-aware code on core

that is not the case with joafip: the data model is managed as a graph
replicated on a file. This is the most important joafip feature.

> logic that should be at least largely unaware of that aspect, that it
> doesn't support any kind of ad hoc query mechanism that I can see, and
> that it doesn't do any better at supporting an object model than
> existing, robust, flexible solutions like every JPA implementation.

Yes,but: I believe your right at a big database point of view and
flexibility needs. In project trigered joafip, we have a data model
easy to code using collections, but I think more complex to code using
request feature, may be not, but so easy to code it in java.

> I've been working with databases, including both relational and
> network-model systems, for nigh thirty years, and attempts to create
> "object-oriented" data systems since "object-oriented" became a
> buzzword. *None of the OODBs or ORMs were worth a damn until Hibernate,
> and since then, JPA rolled out. *

> Now you come along, re-inventing the
> wheel but ignoring things like suspension, springs, shock absorbers,
> bearing grease, ...
>
wheel bycyclette against wheel space shuttle. This is not comparable.
May be in the example I should warn that this is a limited solution.
And gives link to very large brothers you mentionned.

in short, joafip as a database solution is under ancle of existing
framework, I confirm, but why a truck to move an eggs ?

> It is obvious that a lot of work went into it, and within the severe
> limitations of its programming model it seems rather complete. *It's
> just that I can write cleaner code, with more robust data interaction
> and safety, and more convenient management of the underlying data
> persistence, with more flexibility going forward, and the comfort of
> knowing there's a large support framework, and I will bet dollars to
> doughnuts far better performance especially under heavy or heavily
> concurrent load, by going with a JPA solution like Hibernate,
> TopLink/EclipseLink or OpenJPA.
>
doughnuts caviar ?
may be, measurement needed.

>
> Feel free to answer point by point with substantiable arguments.
>
> --
> Lew

Thank you to do the comparison with existing persistence solutions,
even if you wanted I do it for you.
And also thank you to share your network database knoledge.

Luc Peuvrier

On 07-02-2010 17:36, Tom Anderson wrote:
> On Sun, 7 Feb 2010, Lew wrote:
>> Tom Anderson challenged you to show how your project differs from JDO,
>> the failed predecessor to JPA.
>
> I didn't actually do that - i observed that it was the same. I wasn't
> expecting the OP to disagree!
>
> I wouldn't describe JDO as failed, either. It was a technical success,
> but just a commercial failure, IMHO because there's so much inertia
> around RDBMSs.

Hm.

Most actual JDO usage were as an ORM for a RDBMS.

Arne

Lew wrote:
>> coding and a pedagogical perspective. Your "item entity" example has a
>> constructor that calls 'super()' although the type descends directly
>> from 'Object' and 'super()' is called regardless.

luc peuvrier wrote:
> Java good practise say to call super, and PMD I use warning if missing

Nope. Terrible practice. Stupid to call 'super()' when it happens anyway.
PMD obviously a piece of crap.

Lew:
>> It uses 'float' to
>> represent a monetary amount. One might argue that it's "just" an
>> example, but that lack of attention to detail in the visible example
>> makes one worry whether you pay enough attention in the library code.

luc
> Logic ! If I use a float for a monetary amount, who can imagine I can
> write a quality code !

Precisely.

> just between us, after 30 years of programming I have never handled
> monetary data: surprise, right?
>
> I am really happy to learn than float is not proper.

Think about the reasons why.

Lew:
>> The far more serious flaws with the joafip library are that it recreates
>> the ancient network database model, where all the data relations are
>> predefined,

luc:
> Yes,but: relations between object are coded in class, a fixed data
> model.
> I do not know that serialize this fixed data model is the ancient
> network database model...

<http://en.wikipedia.org/wiki/Network_model_(database)>

Lew:
>> that it imposes a lot of data-storage-aware code on core

luc:
> that is not the case with joafip: the data model is managed as a graph
> replicated on a file. This is the most important joafip feature.

The examples in your project contradict that assertion.

luc:
> in short, joafip as a database solution is under ancle of existing
> framework, I confirm, but why a truck to move an eggs ?

Sorry? Your meaning could not be less clear.

How do you think eggs get to the supermarket, by fairy wand?

--
Lew

On 8 fév, 04:23, Lew <no...@lewscanon.com> wrote:
> Lew wrote:
> >> coding and a pedagogical perspective. *Your "item entity"
> >> example has a constructor that calls 'super()' although the
> >> type descends directly from 'Object' and 'super()' is called
> >> regardless. *
> luc peuvrier wrote:
> > Java good practise say to call super, and PMD I use warning if
> > missing
>
> Nope. *Terrible practice. *Stupid to call 'super()' when it
> happens anyway. PMD obviously a piece of crap.
>
Luc:

Your opinion is binding on you
PMD is not piece of crap, really unperfect and not intelligent, but
sometime helpful.
about call of super(): "good practice": a religious war, a war again.
http://java.sun.com/docs/books/tutor...ndI/super.html
call to super is added by compiler when missing.
The good practice in my team, is to explicitly write the super() call,
in fact it it is a convention.
I waill like this practice for eternity, even if you think it's stupid

> Lew:
>
> >> It uses 'float' to represent a monetary amount. *One might
> >> argue that it's "just" an
> >> example, but that lack of attention to detail in the visible
> >> example
> >> makes one worry whether you pay enough attention in the library > >> code.
>
> luc
>
> > Logic ! If I use a float for a monetary amount, who can imagine > > I can
> > write a quality code !
>
> Precisely.

Luc:
perfection is not of this world, may be you apart ?
Your way of thinking is your freedom.
focusing on crap, everything is shit ...

>
> > just between us, after 30 years of programming I have never handled
> > monetary data: surprise, right?
>
> > I am really happy to learn than float is not proper.
>
> Think about the reasons why.
>

Luc:
float is an approximate numeric datatype, as defined by ANSI
standards.
http://stackoverflow.com/questions/2...alues-in-java:
"Martin Fowler recommends the implementation of a dedicated Money
class to represent currency amounts, and that also implements rules
for currency conversion."


> Lew:
>
> >> The far more serious flaws with the joafip library are that it
> >> recreates
> >> the ancient network database model, where all the data
> >> relations are
> >> predefined,
>
> luc:
>
> > Yes,but: relations between object are coded in class, a fixed
> > data model.
> > I do not know that serialize this fixed data model is the ancient
> > network database model...
>
> <http://en.wikipedia.org/wiki/Network_model_(database)>
>

Luc:
Thank you for the references !
joafip enable to only create Navigational_database
http://en.wikipedia.org/wiki/Navigational_database
A pure java object model is navigational, replicate in a file and thi
become a old fashion navigational_database. Cool !
Thank a lot Sir.


> Lew:
>
> >> that it imposes a lot of data-storage-aware code on core
>
> luc:
>
> > that is not the case with joafip: the data model is managed as a
> > graph
> > replicated on a file. This is the most important joafip feature.
>
> The examples in your project contradict that assertion.
>

Luc:

Not at all, the code is:
session.open();
itemTable = (ItemTable) session.getObject("itemTable");
.....
session.close(EnumFilePersistenceCloseAction.SAVE) ;

Do you think I should add comment ?


>
> luc:
>
> > in short, joafip as a database solution is under ancle of
> > existing
> > framework, I confirm, but why a truck to move an eggs ?
>
> Sorry? *Your meaning could not be less clear.

Luc:

(bad idea to translate a french expression)
to be not a patch on sb (British)
* (=much less good than) "ne pas arriver à la cheville de qn"
I rephrase:
in short, joafip as a database solution do not a patch on existing
framework, I confirm, but why a truck to move one egg ?


>
> How do you think eggs get to the supermarket, by fairy wand?
>

Luc:

I love fairy !

how the egg is from the tail of a chicken to the farm basket ?

> --
> Lew

Prologue:

thank you for your informed opinion. even if you are aggressive, may
be the price to pay to be in relationship with a great expert.

The Dai Lama said something like: "My Enemy is my guru, he taught me
about myself more that will have made a good friend"

Joafip do not suffer of this exchange, makes possible a clear focus
for what it is made for.

This world confuses "against" and "complementary": just a question of
context, and contexts are manifold.

Best regards
Luc

On 7 fév, 23:01, Arne Vajhøj <a...@vajhoej.dk> wrote:
> On 07-02-2010 05:37, luc peuvrier wrote:
>
> > what do you think of
> >http://joafip.sourceforge.net/database/dbvsjoafip.html
>
> I think the author is spamming to much in this group ....
>
> Arne

As you want.
But take a look to exiting exchanges with Lew,
But so much interesting topics for the persistence and databases
Luc

In article <hkmrjo$9lg$1@news.albasani.net>, lew@lewscanon.com says...
> Your "item entity" example has a
> constructor that calls 'super()' although the type descends directly
> from 'Object' and 'super()' is called regardless.

There's nothing wrong with that. In future someone could change the
extended class and need not worry about the constructors.


--
stirr your cofee properly

luc peuvrier wrote:
> On 7 fév, 23:01, Arne Vajhøj <a...@vajhoej.dk> wrote:
>> On 07-02-2010 05:37, luc peuvrier wrote:
>>
>>> what do you think of
>>> http://joafip.sourceforge.net/database/dbvsjoafip.html
>> I think the author is spamming to much in this group ....
>>
>> Arne
>
> As you want.
> But take a look to exiting exchanges with Lew,
> But so much interesting topics for the persistence and databases
> Luc

Let me ask what I believe is a relevant question, Luc: have you used
either Hibernate or Toplink Essentials/EclipseLink, with JPA 1.0, to any
reasonable extent? By "reasonable" I mean a non-trivial application that
requires a broad mix of persistence design decisions.

I think you can see why I ask the question. If you haven't used JPA with
either, isn't writing something new a misguided labour? If you have used
either or both persistence providers, why exactly were they so
deficient? I'm curious.

Or what about iBatis, which I'm personally quite fond of? Point being,
and this is just my opinion, you shouldn't waste your time solving
nonexistent problems. And you wouldn't be the first person announcing
new persistence frameworks on this NG...to me it seems like you guys
would be performing a greater service to the community by tackling real
problems. :-)

AHS

Pitch wrote:
> In article <hkmrjo$9lg$1@news.albasani.net>, lew@lewscanon.com says...
>> Your "item entity" example has a
>> constructor that calls 'super()' although the type descends directly
>> from 'Object' and 'super()' is called regardless.
>
> There's nothing wrong with that. In future someone could change the
> extended class and need not worry about the constructors.

As they could without explicitly calling 'super()'. What's your point?

--
Lew

In article <hkpc4a$oe1$2@news.albasani.net>, noone@lewscanon.com says...
>
> Pitch wrote:
> > In article <hkmrjo$9lg$1@news.albasani.net>, lew@lewscanon.com says...
> >> Your "item entity" example has a
> >> constructor that calls 'super()' although the type descends directly
> >> from 'Object' and 'super()' is called regardless.
> >
> > There's nothing wrong with that. In future someone could change the
> > extended class and need not worry about the constructors.
>
> As they could without explicitly calling 'super()'. What's your point?

They may forget to call super()

--
stirr your cofee properly