Prev: Could this unclosed() byteArrayInputStream cause high Heap usage ?
Next: large XML files
From: luc peuvrier on 8 Feb 2010 14:55
On 8 fév, 11:31, Arved Sandstrom <dces...(a)hotmail.com> wrote:
> luc peuvrier wrote:
> > On 7 fév, 23:01, Arne Vajhøj <a...(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

> AHS said:
>
> 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 never use ORM solution.

> AHS said:
>
> I think you can see why I ask the question.

Luc:
Yes, it seems stupid to write a library whithout knowing existing
solutions ! in fact, yes, it is stupid, but not stupid to write
joafip, joafip is not an ORM, it is an object persistence in a file
library.

> AHS said:
>
> If you haven't used JPA with
> either, isn't writing something new a misguided labour?

Luc:
A really exiting labour (for me)

> AHS said:
>
> If you
> have used
> either or both persistence providers, why exactly were they so
> deficient? I'm curious.

Luc:
This is a good question: why for develop joafip ?
Because the problem it been ask me to solve was:
- do not use the database of the application because too much busy to
integrate data.
- cache the data model in a file
- avoid spend execution time in ORM mechanic
And the data entity to store is quite complex at relational object
point of view.
joafip concept is simple: a serialization in file that only write
changes and use lazy load to avoid reload all in memory.

> AHS said:
>
> 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.

Luc:
because iBatis is an ORM front of a database.
the problem to solve exist.

> AHS said:
>
> And you wouldn't be the first person
> announcing
> new persistence frameworks on this NG...

Luc:

> AHS said:
>
> to me it seems like you
> guys
> would be performing a greater service to the community by tackling
> real
> problems. :-)

Luc:
it seems that the problem I had to solve is not common.
thank you for inviting me to be more useful.
May be this NG is not the right place for my subject

>
> AHS

From: Lew on 8 Feb 2010 15:41
luc peuvrier wrote:
> Yes, it seems stupid to write a library whithout knowing existing
> solutions ! in fact, yes, it is stupid, but not stupid to write
> joafip, joafip is not an ORM, it is an object persistence in a file
> library.

"ORM" is a means to the same end that joafip seeks. That joafip is not an ORM
is not relevant. That it and ORM both handle persistence of an object model
is relevant. Thus, joafip has to compete with ORM solutions, among others.

AHS said:
>> If you have used either or both persistence providers,
>> why exactly were they so deficient? I'm curious.

Luc:
> This is a good question: why for develop joafip ?
> Because the problem it been ask me to solve was:
> - do not use the database of the application because too much busy to
> integrate data.

Who or what was too busy? People or machines?

Modern ORM solutions can provide no-effort persistence for the types of simple
problems joafip purports to handle. Discounting the effort of creating a
custom solution like joafip, the two seem not to differ much in that regard.

> - cache the data model in a file

Why a file? How is that better than in a database?

I can certainly see how it'd be better to "cache" the data in a database than
a file, but the argument the other way eludes me.

> - avoid spend execution time in ORM mechanic

That means you measured how much execution time is spent "in ORM mechanic[s]"
and in your persistence solution, and you have hard numbers as to the advantage.

What are they?

> And the data entity to store is quite complex at relational object
> point of view.

Could you explain that in more detail? Using JPA, the storage is only complex
if the entity model is complex. For the most part, the JPA framework can
deliver the data model to back the object model without programmer effort.
Where does that mechanism break down? How does joafip do it better?

Based on the sample code on the project site, the joafip version of code is no
less complex than an equivalent JPA solution would be.

> joafip concept is simple: a serialization in file that only write
> changes and use lazy load to avoid reload all in memory.

Again, that's no different from what existing, mature solutions do.

AHS said:
>> 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.

Luc:
> because iBatis is an ORM front of a database.
> the problem to solve exist.

That does not follow. You are assuming your conclusion, that an ORM in front
of a database is a problem. It is not.

--
Lew
From: Arne Vajhøj on 8 Feb 2010 20:17
On 08-02-2010 02:09, luc peuvrier wrote:
> On 8 f�v, 04:23, Lew<no...(a)lewscanon.com> wrote:
>> Lew wrote:
>>> 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/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."

That is one option.

java.math.BigDecimal may be good enough for many cases.

Arne
From: Arne Vajhøj on 8 Feb 2010 20:19
On 08-02-2010 14:55, luc peuvrier wrote:
> On 8 f�v, 11:31, Arved Sandstrom<dces...(a)hotmail.com> wrote:
>> 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 never use ORM solution.

Maybe not.

But I would guess that 80-90% of persistence in Java
in real apps are done using some type of ORM.

So natural that is what a persistence solution will be compared
to.

Arne
From: luc peuvrier on 8 Feb 2010 23:31
On Feb 8, 9:41 pm, Lew <no...(a)lewscanon.com> wrote:
> luc peuvrier wrote:
> > Yes, it seems stupid to write a library whithout knowing existing
> > solutions ! in fact, yes, it is stupid, but not stupid to write
> > joafip, joafip is not an ORM, it is an object persistence in a file
> > library.
>
> "ORM" is a means to the same end that joafip seeks.  That joafip is not an ORM
> is not relevant.  That it and ORM both handle persistence of an object model
> is relevant.  Thus, joafip has to compete with ORM solutions, among others.
>
> AHS said:
>
> >> If you have used either or both persistence providers,
> >> why exactly were they so deficient? I'm curious.
>
> Luc:
>
> > This is a good question: why for develop joafip ?
> > Because the problem it been ask me to solve was:
> > - do not use the database of the application because too much busy to
> > integrate data.
>
> Who or what was too busy?  People or machines?

Luc:
machine was busy.

>
> Modern ORM solutions can provide no-effort persistence for the types of simple
> problems joafip purports to handle.  Discounting the effort of creating a
> custom solution like joafip, the two seem not to differ much in that regard.

Luc:
- Yes it is, I believe in ORM solutions according to description I
read and according to your remarks.
- The two solution differs: ORM have database as bakend layer, joafip
persist an object graph in a file. joafip is between a "classic"
serialisation ( native serialization, xml encoder/decoder, xstream ..)
and high level ORM solutions.

>
> > - cache the data model in a file
>
> Why a file?  How is that better than in a database?
>

Luc:

I had to obey to my project manager and architect.
I understood they want to reduce stacking layer between the objets in
memory and the bytes in the file.

> I can certainly see how it'd be better to "cache" the data in a database than
> a file, but the argument the other way eludes me.
>
> > - avoid spend execution time in ORM mechanic
>
> That means you measured how much execution time is spent "in ORM mechanic[s]"
> and in your persistence solution, and you have hard numbers as to the advantage.
>
> What are they?
>

Luc:
A team member validate the storage performance using joafip in our
application context.
According to your question, I should compare with ORM+database
solutions.

> > And the data entity to store is quite complex at relational object
> > point of view.
>
> Could you explain that in more detail?  Using JPA, the storage is only complex
> if the entity model is complex.  For the most part, the JPA framework can
> deliver the data model to back the object model without programmer effort..
> Where does that mechanism break down?  How does joafip do it better?
>
> Based on the sample code on the project site, the joafip version of code is no
> less complex than an equivalent JPA solution would be.
>
> > joafip concept is simple: a serialization in file that only write
> > changes and use lazy load to avoid reload all in memory.
>
> Again, that's no different from what existing, mature solutions do.

Luc:
The only difference is that ORM store object fields in database table
record. joafip write object state in a file binary data record.

>
> AHS said:
>
> >> 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.
>
> Luc:
>
> > because iBatis is an ORM front of a database.
> > the problem to solve exist.
>
> That does not follow.  You are assuming your conclusion, that an ORM in front
> of a database is a problem.  It is not.
>
> --
> Lew

Luc:
I never said "is a problem". I repeat, I beleive in ORM solution
according that I learn on it and according to your attestation.
All things can be a problem or solution: each solutions have good and
bad point according to a criteria list.
I do not want joafip be used in context where it exist best solutions.

In fact, to be agnostic, I have to works on a list describing wich for
joafip is good for and wich for is bad for.

Thank for your help

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11
Prev: Could this unclosed() byteArrayInputStream cause high Heap usage ?
Next: large XML files