Guyren, Hi! There doesn't seem to be have a huge amount of direct interest in this, but I'd be _really_ interested in utilising this OR code. I'm currently undertaking a project for which I planned to implement this layer by hand.
I don't think I've got necessary skills to help improve the framework at this time, but maybe a few months down the line. Regards, Narinder. -- ___________________________________________ | Narinder Chandi, | ToolBox Systems Limited, | Surrey, England, UK. | tel/fax : +44 (0)1372 720117 | mobile : +44 (0)7973 512495 | skype : NarinderChandi | www : http://www.toolbox.uk.com |___________________________________________ | Consultancy * Development * Support | * 4D Solutions Partner since 1998 * |___________________________________________ on 25/7/06 14:42, [EMAIL PROTECTED] at [EMAIL PROTECTED] wrote: > Subject: Interest in LGPL O-R code? > From: Guyren Howe <[EMAIL PROTECTED]> > Date: Tue, 25 Jul 2006 08:43:59 -0500 > > I've developed a substantial Object-Relational mapping layer for a > current job. My client is amenable to releasing the code under a LGPL > license, if there is interest in the community in pitching in to > develop the code further. So I'm here to ask: who would be interested > in helping to develop this code? > > The code as it stands will work with a custom database (it uses > column naming conventions to assist in the mapping), and uses > Operator_Lookup to assist with the mapping. > > The code maps tables (other than many:many join tables) to classes. > By using Operator_Lookup, column names in the database are > automatically converted to properties, and the code tracks > modifications to properties, so only objects and properties that have > been modified are written back out to the database. Writing to the > database is a single call with no arguments; the code using the data > layer objects just uses them. The call to write the changes out could > potentially be called from a timer (although you would really want to > use a thread rather than a timer, and I've not finished making the > code thread safe). > > The current code also deals with joins (one:many and many:many). A > join appears as a Set on one or both ends, and changes to one end are > copied automatically to the other end. > > Absent weak references, the current code needs to keep objects in > memory once instantiated (but if there was significant interest in > this project, it might prompt more requests for weak references, > hastening this important feature's arrival). > > The code could be developed in many ways: making it work without the > column naming (so with any database); implementing the periodic, > threaded flush (so you could just forget about explicitly saving); > having more of the SQL automatically generated; making it work with > more SQL dialects than SQLite; using IDE scripting to make the > boilerplate code more auto-generated; supporting other data source > types (SOAP, XML, ...). Interestingly, this framework would fairly > cleanly form the basis of a networked server framework, where one > REALbasic application serves up the data to many others. > > So: who, if anyone, would be interested in pitching in to improve > this framework? > > Guyren G Howe _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives of this list here: <http://support.realsoftware.com/listarchives/lists.html>
