cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Antonio Gallardo" <agalla...@agsoftware.dnsalias.com>
Subject Re: DB support in flowscript (was: XSP "official" position)
Date Wed, 19 Nov 2003 19:36:17 GMT
Leszek Gawron dijo:
> Continuing the example: cocoon is very powerful in presenting reports. I
> haven't seen a single report tool that does O/R mapping.

Please wait, it is very early to said that. O/R is very new and of course
you are right, but it is just a matter of time.

I don't said O/R tools are the panacea to all our problems, but mixing SQL
+ XSP is ugly even if you take advantage of stored procedures. Believe me
I, we ended a payroll proyect and it was the worst can us happen: SQL+XSP
it is almost unreadable.

> Continuing II: I still cannot picture retrieving 5000 of objects via O/R
> and
> showing them on paginated view - the performance would be tragical.

Depends how you do that. For example OJB support proxies and cache.

>> >   - sometimes the db schema makes it impossible to use O/R tools

Show me one. This also denote SQL can be abused. Just for the records, we
are currently building an accounting system and O/R works fine there. This
is the example you said: a 150+ tables.

Who said O/R mapping need to be wroten by hand? This is not a MUST
anymore. This is mainly why I go to Druid. Did you know Druid? If not here
is the link: http://druid.apache.org/ :-D

Using Druid making an O/R mapping is a matter fo secs! Is this a problem?
Also + your Beans ready to be used. Well the Beans for JDO are a little
bit slower. But I am sure you will have in less than 2 mins you
database.jar ready to use. So where is the problem? :-DD

As you see we are doing some improvements. I like to think we are
innovating in this area. An of course the path is not easy. But I think we
will find a Regards at then end.

We are learning, how to work with all this stuff and this allow us to
think new ideas to be implemented. But please wait, we need also to
implement the new ideas too.

Of course you can said us: Hey, wait a minut, there is
XSP+ESQL+ModActions, why use flow+OJB+JDO at all? Well, let us even fail.
If we fail this is a lesson for the community too: The path is wrong.

>> that's possible ...
>>
>> >   - in 2 years I haven't found a single project that does not
>> > fall under one
>> >     of above conditions
>> >
>> > I would really like to contribute to some flow-db block that
>> > does not involve O/R mapping but do not know where to start from.
>> >
>>
>> Maybe this helps - I like the idea but don't know if this will work ...
>> but I think it worth following it.
>> http://marc.theaimsgroup.com/?t=106761394400006&r=1&w=2
>> (... but it would be OJB based)
>>
>> What I don't want to see in a flow-db block is SQL statements ...

+1

> I think that it should be possible to choose between O/R and pure database
> access. O/R could be a proposed solution and JDBC wrapper a backup one.
> 	ouzo

Also, please wait. As soon as we will have time you will see your petstore
using OJB too. But just because there is not the OJB petstore this does
not mean it can not exists. It is a matter of time. I repeat.

Best Regards,

Antonio Gallardo


Mime
View raw message