I was under the impression that you considered further development of OPL to
be outside the scope of an open source project. It's good to hear that you
are still developing it.
----- Original Message -----
From: george stewart <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 29, 2000 7:15 AM
Subject: postgres and other db woes (long)
> Nissim and Sean,
> I wish you guys would try to integrate my OPL into
> Turbine. Seriously, it would be much easier to deal
> with db differences using a system which has a mapping
> layer like Castor or OPL. OPL would be easier for you
> guys because it supports criteria objects and is a
> much smaller system.
>
> Recently, many of the development issues have some
> connection -- no pun intended ;-) -- to the database
> access.
>
> I will have the new OPL in a public CVS within 2
> weeks.
>
> While adding this, you could rework Turbine so it has
> "hooks" for data access so you could plug in either
> the Peer model, OPL, or some other system. By making
> this more open with clean interfaces, you broaden
> Turbine's appeal.
>
> Since my last posting of source to Turbine users, I've
> made the following changes / additions to OPL:
>
> 1. Replaced use of attributed interface with vectors.
> This uses fewer objects so should be faster, more
> efficient.
>
> 2. Modeling Oleg Nitz's code in Castor, I added key
> generation for max key, auto-increment, and sequence.
>
> 3. Added auto-update of foreign key values in
> dependent tables.
>
> 4. Added Castor's (Assaf Arkin's) type conversion
> features. I'm packaging Assaf's code for type
> conversion in the distribution. It's so clean, I can
> use it with zero code changes.
>
> You can see that I really like Castor. Problem for me
> with Castor is that Castor is moving toward being more
> O-O to be consistent with Sun's standards. Castor
> doesn't have support for Criteria objects, and it's
> unlikely you'll ever have the low-level access that's
> in OPL.
>
> While programming, you have the criteria data. With
> Castor, you take this criteria and formulate an OQL
> query, which is given to an OQL parsing engine, and
> then the parsing engine builds criteria objects which
> are used to build the query expression. With OPL, you
> build these objects directly.
>
> A note to Turbine / Castor users is that OPL has
> support for multi-valued keys and using connection
> pooling. In the code, you aren't aware of the
> pooling; it's implemented with configuration.
>
> For users, the major problem in using Castor or OPL is
> editing the class maps. I will write a schema for the
> mapping, and, hopefully, you could use Xeena to edit
> the maps.
>
> - george
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Get Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
