From: george stewart <georgestewartiv@ya...> - 2001-02-07 23:56:46
--- Mark <mark@...> wrote:
> Hi George:
> Just starting to use Osage, it is very cool. Count
> me in
> as being a future tester!
> Got a couple of questions/suggestions (I can't login
> sourceforge at the moment for some reason).
> When compiling, against the latest version of Castor
> (0.8.11?), you'll need to change the
> osage/util/builder/ClassGenerator.java file.
> Changes are
> fairly small, basically some classes became
> interfaces and
> objects adjusted (looking at their changelog). cvs
> diff at
> the end of this note if useful.
Thanks for patch.
> On an unrelated note, does osage support the use of
> inheritence in any form? Artyom's
> layer (also referenced from Scott's persistence
> page) does
> support this concept and I think it is nice.
No it doesn't. Yes that nice concept. If anyone can
provide nice patch for this, I'll apply it.
> other feature that Artyom's PL supports is the idea
> a "PersistentObject". Basically, for doing
> persistence, it
> is possible to extend this object in java and simply
> call "save/delete/retrieve". This provides a much
> approach to using persisted objects. What are you
> on the difficulty of adding this (I may give it a
> anyway) by creating this type of object that uses
> appropriate Critieria objects behind the scenes?
I think it's better not to require base class, so
people can use legacy classes or whater. I would like
to implement call back interface like castor's.
> The only features I need that castor doesn't
> provide are BLOB/CLOB support. I need to add that
> in ASAP
> (perhaps you can provide pointers what may exist
I'm hoping that it already supports clob/blob
retrieval. It's a big pain to save. I recommend
using separate table for each clob/blob, and just use
> Also, where would there ever be the need to create a
> where the attributes would be mapped to multiple
You can, but it's view only. No saving, update, etc.
> Can this do the "inheritenace" thing I mentioned
For retrieval. But it's a pain. You have to specify
the join criteria for every retrieval. If the
database supports views, you could use this instead.
> Other issue relates to the problem reported for
> a classmap based on what is in a database for
> oracle. I
> too had the same issue and what I did (better or
> worse) was
> to limit the schema on the export in
> ~util/builder/MapBuilder.java by something like:
> metaData = conn.getMetaData();
> ResultSet tables = metaData.getTables(null,
> metaData.getUserName(), "%", tableTypes);
Would it be too much trouble for the user to provide a
list of tables? This wouldn't be too much trouble to
> Sorry this was so long with so many ideas thrown in.
Thanks for your interest and input. I think osage is
easy enough to use. I would like to focus my efforts
on efficiency, change detection and object cache.
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.