RE: DB Alternatives to DODS

That's OK, I can wait...
David

Quoting Christian Cryder <[email protected]>:

> 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
> 
> _______________________________________________
> Barracuda mailing list
> [email protected]
> http://barracudamvc.org/lists/listinfo/barracuda
>