-Brian
On Monday, September 15, 2003, at 03:58 PM, Edson Carlos Ericksson Richter wrote:
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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
