On Monday 10 December 2007 12:12:19 Paul-Michael Agapow wrote: > Yowser. Thanks to both of you - that's exactly what I mean. Any > pointers on where I can find an example of a class that is > "unaware" if it is in the db? Or is there a good example of the > second solution, of "a single class that does the what and why, > and an interchangeable layer/context that does load/saving"? I'm > digging through dbcook.sf.net but haven't found anything just yet. well... good example - no. there is a bad example: dbcook/dbcook/usage/example/example1.py The classes are plain classes (.Base can be anything/object), with some DB-related declarations/metainfo in them. they do not have to know that they are DB-related. if u dont give them to dbcook.builder.Builder, they will not become such. If u give them, they will become SA-instrumented etc, but u still do not have to change anything - as long as your methods do not rely (too much) on being (or not being) DB. see dbcook.expression as attempt to wrap some queries in independent manner.
more, if u redefine the Reflector u can have different syntax for db-metainfo - or get it from different place, not at all inside the class. So u can plug that in and out whenever u decide to (no example on this, its theoretical ;-). Still, the final class (or object) will be always aware about being in the db or not; it is _you_ who should know when u do not care (95%) and when u do (5%). All this is "proper design and then self-discipline" issue: u have to keep the things separate (and i tell u, it is NOT easy) if u start putting it any db-stuff in the classes, no framework will help u. complete opaque separation is probably possible, but will probably mean having 2 paralel class hierarchies instead of one. > On 2007 Dec 7, at 22:07, [EMAIL PROTECTED] wrote: > > Paul Johnston wrote: > >>> "A Sample may be created by the web application or fetched from > >>> the database. Later on, it may be disposed of, edited or > >>> checked back into > >>> the db." > >> > >> Sounds like you want your app to be mostly unaware of whether a > >> class is > >> saved in the db or not (i.e. persistent)? If so, I'd use a > >> single class, > >> design the properties so they work in non-persistent mode, and > >> then they'll work in persistent mode as well. > > > > or like a single class that does the what and why, and an > > interchangeable > > layer/context that does load/saving (and the relations!). > > in such situations declarative programming helps a lot, so u dont > > bind your > > self to (the) db (or whatever persistency). Check dbcook.sf.net. > > My own > > latest experience is about turning a project that was thought for > > db/using > > dbcook into non-db simple-file-based persistency. The change was > > relatively > > small, like 5-10 lines per class - as long as there are > > Collections etc > > similar notions so Obj side of ORM looks same. > > -- > Dr Paul-Michael Agapow: VieDigitale / Inst. for Animal Health > [EMAIL PROTECTED] / [EMAIL PROTECTED] > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
