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
