----- Original Message -----
From: george stewart <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, December 26, 1999 9:09 PM
Subject: more changes
> Scott,
> I know you have to be getting tired, annoyed at all
> these changes.
well yeah... you are wearing me down... i finding it hard to keep up with
you... but don't let that stop you.
>
> I promise to slow down. I'm racing to get insert,
> delete, and select (CRUD, in Scott's paper) fully
> working. I can't rest peacefully until I do.
>
freaking fantastic... i love it when something puts me into this mode... i
think that athletes call this "...being in the zone..."
> Definitely, it's time for a consolidation phase in my
> efforts. I need to spend some time exercising and
> testing this stuff. My recent changes should make
> this easier.
>
> As we've discussed, it would be nice to have something
> for retrieving the maps. I'm not gung-ho for doing
> this. It needs some design (Scott didn't give this
> one up), and I'm a coder not a designer. Maybe, we
> can find something on the internet about this. Tons
> of people must be using this meta-data approach.
>
well i'm not sure what you mean by "meta-data approach". do you mean to use
the system tables (meta-data) of the RDBMS? if this is the case i have to -1
on this. my reasoning is it will be out of our control what each RDBMS
vendor stores in its systems tables making it unpredictable. I would rather
create our own table schema or XML DTD to store this data and create a
utility application to help maintain the data.
> The only other thing I'm eager to implement is the UDA
> maps. This is a really nice piece of Scott's design,
> and is a major source of it's power.
well to be honest, this has always been a question mark for me... i'd like
to see how are iterpreting the design.
> For the example, I'll hand-code the stuff for
> attributes. You could also use a generator for the
> accessor methods, but I think Scott's design will get
> more use if introspection is used. I haven't actually
> coded anything using this, and I know it's a last
> resort technique. But the accessor methods of the P.O.
> design look like a classic case for it's use. I
> should post something on Turbine about this to reopen
> the discussion.
>
yes do this... i know that the use of introspection was objected to by some
on the list. although i'm not totally against it, i think the idea of making
the coding standard be that all PO's need to conform to the JavaBean
standard is still a viable solution.
> btw, I added Cursor.java under database. Do we need
> PersistentCursor in api?
>
the reason that it is in /api is becouse SA's white paper states that:
"...an application programmer only need to know about the folloing classes
to make their object persistent: PersistentObject, the PersistentCriteria
class hierarchy, PersistentTransaction and _Cursor_...", thus making up the
API. so i think it should stay where it is.
-scott-
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
