Is not same as "Combined Disk and In-Memory Operation"
(http://hsqldb.sourceforge.net/web/hsqlModes.html)???

Edson

----- Original Message ----- 
From: Brian McCallister
To: OJB Users List
Sent: Monday, September 15, 2003 5:10 PM
Subject: Re: Prevayler based PB implementation


Prevayler is a completely different idea from a relational database.
HSQL in-memory is great for a lot of things (persistence not being one
of them). Prevayler basically acts as a heap that survives restarts.

-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]


---
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]

Reply via email to