RE: DB Alternatives to DODS

Hi David, what's your timeframe on this? I could probably get you something
to look at, but it might take a bit - I have test cases and examples, but
its still undergoing tweaks, plus I haven't written any docs on it yet, plus
we're in the middle of implementation so things are pretty busy
timewise...you might have to do a bit of "figuring it out" on your own. Not
sure how comfortable you'd be with that...

Christian
----------------------------------------------
Christian Cryder [[email protected]]
Internet Architect, ATMReports.com
Barracuda - http://barracudamvc.org
----------------------------------------------
"Coffee? I could quit anytime, just not today"

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of David R Robison
> Sent: Friday, February 28, 2003 4:44 PM
> To: [email protected]
> Subject: RE: [Barracuda] DB Alternatives to DODS
>
>
> I would be interested in seeing some sample code for your OR
> classes if it is
> available…
>
> David R Robison
> Open Roads Consulting, Inc.
> http://www.openroadsconsulting.com
>
> Quoting Christian Cryder <[email protected]>:
>
> > Hi David,
> >
> > We _don't_ use DODS. I've never been much impressed with it (and I did
> > a
> > fair amount of work with the newest version of it while I was still at
> > Lutris)...just not how I like to approach OR mapping. There are a number
> > of
> > other OR mapping packages out there, but most of them were heavier
> > weight
> > than what we wanted, so we ended up rolling our own solution, and at
> > some
> > point when it gets a little further along (and I get a little less
> > busy), we
> > may make it publically available.
> >
> > What we really wanted something lightweight to map the JDBC result sets
> > into
> > nested list/map data structures. Specifically, we thought the data
> > layer
> > should
> > a) make no requirements of the SQL DB structure
> > b) give us complete access to the SQL layer - we write it, rather than
> > letting the tool do it for us
> > c) give us the ability to easily write test cases for the sql layer (so
> > we
> > can validate all the SQL in the app at any given point)
> > d) automatically support the lazy loading of data (so that nested data
> > wasn't actually loaded until it was needed) and nested transactions
> > (save
> > the data at any point in the hierarchy and everything below it gets
> > saved)
> > e) support different keying mechanisms - simple surrogate keys vs
> > complex
> > aggregate keys; self assigned identity keys vs. autocreated identity
> > keys
> > f) be very easy to program against
> >
> > As an example of what we came up with, consider the following table
> > structure:
> >
> >
> >
> > Let's say I want to iterate through all the Terminals for Business ATMR.
> > I
> > would simply do this:
> >
> > BusinessList list = new BusinessList();
> > list.putKey(BusinessMap.COMPANY_ID, Companies.ATMR);
> > list.load();
> > for (int i=0; i<list.size(); i++) {
> >     BusinessMap map = (BusinessMap) list.get(i);
> >     String descr = (String) map.get(BusinessMap.DESCR);
> >     TerminalList tlist = (TerminalList)
> > map.get(BusinessMap.TERMINAL_LIST);
> >
> >     ...iterate through tlist...
> >
> > }
> >
> > The key thing to observe here is that the properties are accessed just
> > as if
> > this was a regular list/map structure. As I'm looping through terminals,
> > I
> > can set properties as needed, then when I'm all done issue a list.save()
> > and
> > the whole thing will be automatically wrapped in a trx. Or I could load
> > an
> > individual Terminal all by itself and work with that:
> >
> > TerminalMap tm = new TerminalMap();
> > tm.putKey(TerminalMap.COMPANY_ID, Companies.ATMR);
> > tm.putKey(TerminalMap.BUSINESS_ID, ...);
> > tm.putKey(TerminalMap.TERMINAL_ID, ...);
> > tm.load();
> > ...modify props...
> > tm.save();
> >
> > The whole thing is quite flexible. Not entirely automated (in the sense
> > that
> > we have to write the sql code and manually create the map/list objects,
> > but
> > that's how we wanted it, so that we could have complete control over
> > the
> > thing.
> >
> > So that's how we do OR mapping...
> >
> > Christian
> > ----------------------------------------------
> > Christian Cryder [[email protected]]
> > Internet Architect, ATMReports.com
> > Barracuda - http://barracudamvc.org
> > ----------------------------------------------
> > "Coffee? I could quit anytime, just not today"
> >   -----Original Message-----
> >   From: [email protected]
> > [mailto:[email protected]]On Behalf Of David R Robison
> >   Sent: Thursday, February 27, 2003 7:26 PM
> >   To: [email protected]
> >   Subject: [Barracuda] DB Alternatives to DODS
> >
> >
> >   In the past I've used DODS for my database access in my Barracuda
> > applications. It integrates well with Enhydra and is easy to use when
> > creating a new database. However, I have had trouble getting it to work
> > with
> > legacy databases (tables w/o the version and objected fields). Has
> > anyone
> > used any other tools besides DODS for database access within
> > Enhydra/Barracuda?
> >
> >
> >
> >   David R Robison
> >
> >   Open Roads Consulting, Inc.
> >
> >   http://www.openroadsconsulting.com
> >
> >
> >
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda