object relational database versus "inteligent" serialization

[luc peuvrier]

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.

 

[Lew]

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.

You never answered the questions and comments from people the last time
you spammed for this project.

Except to write me privately and deny that you're a spammer, something
to which this latest post gives the lie.

Oh, you responded, but your responses didn't address the points. For
example, Arved Sandstrom that "persistence providers like EclipseLink
have put a lot of effort into doing 'intelligent' serialization as
described above." You answered that "[t]he joafip goal was to write a
full object data model without take care of memory amount, the object
graph is derecitly backend to file." How does that address the point
that your product doesn't add value compared to, say, EclipseLink? I
don't even understand what you were trying to say there, much less how
it distinguishes your project.

Tom Anderson challenged you to show how your project differs from JDO,
the failed predecessor to JPA. You threw the ball back in his court,
"I will be happy you compare the JOAFIP and JDO facade." When I pointed
out that it's your job to make the comparison for us, your only response
was to (falsely) deny that you're a spammer. You completely ducked
tom's point. What's the matter, afraid your project will suffer for the
comparison?

There is nothing in any description of your project that shows it to
have any advantage whatsoever over any other object-storage or
object-relational-mapping framework. Maybe because your project isn't
offering any such advantage? I'm willing to accept that it might, but
your refusal to delineate any is rather telling, I'm afraid.

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.

You can change that impression and prove me wrong, of course. That is,
if you have anything substantive to say.

 

[Lew]

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.

 

[Arne Vajhøj]

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

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

Arne

 

[luc peuvrier]

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

 

[Tom Anderson]

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

 

[Tom Anderson]

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

 

[luc peuvrier]

You never answered the questions and comments from people the last time
you spammed for this project.

Except to write me privately and deny that you're a spammer, something
to which this latest post gives the lie.

I answered about this to Arne Vajhøj, bad place, sorry.

Oh, you responded, but your responses didn't address the points.  For
example, Arved Sandstrom that "persistence providers like EclipseLink
have put a lot of effort into doing 'intelligent' serialization as
described above."  You answered that "[t]he joafip goal was to write a
full object data model without take care of memory amount, the object
graph is derecitly backend to file."  How does that address the point
that your product doesn't add value compared to, say, EclipseLink?  I

Yes, I can not compare to EclipseLink because I do not know it !

don't even understand what you were trying to say there, much less how
it distinguishes your project.

Tom Anderson challenged you to show how your project differs from JDO,
the failed predecessor to JPA.   You threw the ball back in his court,
"I will be happy you compare the JOAFIP and JDO facade."  When I pointed
out that it's your job to make the comparison for us, your only response

I notice that you are waiting for.
I am happy: it is a good start for discussion.

was to (falsely) deny that you're a spammer.  You completely ducked
tom's point.  What's the matter, afraid your project will suffer for the
comparison?

Suffer ? yes I want ... I explain:
I do not pretend that joafip will take the place of all these
wonderful solutions persistence (which I do not control, that is not
the case for replier: Welcome )

There is nothing in any description of your project that shows it to
have any advantage whatsoever over any other object-storage or
object-relational-mapping framework.  Maybe because your project isn't
offering any such advantage?  I'm willing to accept that it might, but
your refusal to delineate any is rather telling, I'm afraid.

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.

You can change that impression and prove me wrong, of course.  That is,
if you have anything substantive to say.

your answer has the merit of being clear
Thank you again

 

[luc peuvrier]

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.

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

 

[Arne Vajhøj]

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]

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:

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:

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:
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?

 

[luc peuvrier]

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/tutorial/java/IandI/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:


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 ...

Think about the reasons why.

Luc:
float is an approximate numeric datatype, as defined by ANSI
standards.
http://stackoverflow.com/questions/285680/representing-monetary-values-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:


<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:


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:


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 ?

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

 

[luc peuvrier]

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

 

[Pitch]

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.

 

[Arved Sandstrom]

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

 

[Lew]

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

If it had been good, I'd've said so. In fact, given the new information you
provided in response to my challenges I see better the value you aimed for in
joafip, and perhaps achieved.

Luc:

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

Yes, that's it. Even worse, in general there's no reason to use 'float' in
Java except for certain corner cases. Usually 'double' is better. The
difficulty with currency has to do with lack of precision. Even there there
are times when double works, e.g., for interest calculations.

Lew:

luc:

That's the similarity.

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.

You're welcome.

luc:

Lew:
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 ?
Lew:
Luc:
I love fairy !

Moi, aussi, but it doesn't make the idiom more sensible.

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

So you're saying that your project is for laying eggs, and I am comparing to
products that bring them to the supermarket? And that if I wish merely to lay
eggs that your project is less overkill? Do I have that right?

Prologue:

Do you mean "epilogue"?

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.

Oooh! Sarcasm! Snap!

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

That sounds like you consider anyone who criticizes your work an enemy. I am
not your enemy.

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

That's the point.

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

I'm not for or against, simply expressing my observations and conclusions.

 

[Lew]

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?

 

[Pitch]

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

They may forget to call super()

 

[Lew]

They may forget to call super()

And that does no harm whatsoever. I ask again, what's your point?

 

[Pitch]

And that does no harm whatsoever. I ask again, what's your point?

What if the new parent-class has a non-empty constructor that needs to
be called with super()?