On Thursday 28 June 2007 17:50:17 Michael Bayer wrote: > On Jun 28, 2007, at 4:12 AM, svilen wrote: > > i have some opinion/wishes around this one too. > > i have a complete validating/verificating descriptors for all my > > attributes (plus no other attributes are allowed on my > > model-related classes - my static_type framework). Those includes > > type/value-validation, autoconvert, readonly etc etc metainfo. SA > > does overwrite them all with InstrumentedAttributes which basicly > > allow any values to go in. > > curently i'm workarounding most if this by hacking the __dict__ > > descriptor, postfactum, but it does not work 100% (and is slow). > > Sooner or later i'll have to hack the InstrumentedAttrs myself, > > to accomodate/add the behaviour i need. > > > > can we think of some way to nicely replace/overload/tune those > > InstrumentedAttrs - and any other SA-enforced > > descriptors/properties/methods on user's class (e.g.__init__()) - > > into something enhanceable/tweakable by user? > > This may not be an immediate goal, maybe 0.5 or similar.. > > use the column_prefix option so that youre InstrumentedAttributes > get moved away into their own distinctly-named attributes. then > define your own properties to do anything you want. its in the > docs. you can easily make your own mapper() function that does > whatever you want in this regard automatically. yes, this is one way to go. But it will still allow access via the "hidden" SA props, when anyone finds about them, plus the __dict__ is also there. As people always find a "reason" to avoid validators (i wanna break free! off framework), it will surely happen. Src code police? urgh. i may put some simple trigger in the svn not to allow commiting files containing __dict__[] or x._sa_hidden_propr = ... but that gets smelly.
When/if i hack the InstrAttr __get__/_set__,_delete__, i'll tell u what/how i did it. i guess some inheritance would be enough. later svil --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
