Excuse me, but what is wrong with HSQL (or the derivative that is configured to work in-memory? Why can't we devote some time to improve HSQL, if it's not so performatic as we want?
Edson ----- Original Message ----- From: Thomas Mahler To: OJB Users List Sent: Monday, September 15, 2003 4:41 PM Subject: Re: Prevayler based PB implementation Hi Olli, [EMAIL PROTECTED] wrote: > Hej Thomas, > > >>-----Original Message----- > > >>during the weekend I wrote a new PB implementation that is based on >>prevayler (http://sourceforge.net/projects/prevayler/). > > > don't you have any hobbies? :-) I always thought coding is a well respected hobby in our meritocracy ? :-) > >>- A query engine must be implemented. This is the largest >>todo. We need a >>query engine, that is able to perform PB queries against the in-memory >>database. > > > I wonder how this engine would look like. I'm also thinking about this and have not yet a clear picture. > Should it be done via a mapping to SQL? Then it is not our > job but rather an issue for the prevayler project. Of course, > the SQL must refer to a virtual O/R-mapping then. I don't think that the Prevayler team would regard this as within their scope. They care about persisting your business models. But they do not care about querying at all. It's the users responsibility to navigate and search accross the business model. SO if we want to have a SQL engine we'll have to find one or to develop it on our own. Doing it this way would allow to reuse the existing SqlGenerator and it would allow to use bot Criteria and SQL based queries. OTOH i think that it's a lot of work :-( > > Or should it support the PB query API directly? That was my original idea. But there are some tricky issues to solve. Only consider a query against class C with to criteria a and b that are linked by AND. How to avoid 1. a full scan of all C instances to build a collection of all instances matching a.? 2. a full scan of all instances in this collection to filter all instance also matching b? > What about those features in the API that refer to the > Database schema directly (such as SQLQuery)? Sql based queries won't work in this Approach. That's a real disatvantage of this approach. > >> Any ideas for this are welcome. This engine could be reused >>to provide >>in-memory queries for ODMG and JDO. > > > Sounds cool. However, I doubt that it would have essential > impact. For prototyping and testing, HSQL is sufficiently convenient, > and in real life, customers want RDBMS. That is my what I guess > at least. I agree. For most enterprise application that I have seen RDBMS are meant to stay. But I think there are other areas (for instance embedded applications) where some architects would prefer to not use a RDBMS. For these areas a Minimum-footprint solution like OJB/Prevayler could be an ideal solution. Prevayler gained a lot of momentum even for web based applications. But after the first enthusiasm developers see that several things (like transactions, standardized persistence APIs, and queries) are simply not present. So I think there could be a niche market for a OJB/Prevayler OODBMS. (If I'm wrong it was at least fun to code... ) cheers, Thomas > > regards, > Olli > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003
