On Jan 7, 2014, at 2:14 PM, Philip Scott <safetyfirstp...@gmail.com> wrote:
> > The other bit of technology we have that could be unpicked without _too_ much > trouble is a sort of reverse CompositeProperty; many attributes of different > types, including collections, out of one HSTORE column (with a sort of > side-loaded instrumentation for mutation tracking that I think could have > been done in a more idiosyncratic way). > > Paraphrasing a bit but you can do things like: > > class Animal(Base): > data = Column(MutableDict.as_mutable(HSTORE)) > > colour = HsProperty(data, String) > legs = HsProperty(data, Integer) > discovered = HsProperty(data, Date) > fun_facts = HsProperty(data, JSONEncoded(list)) > > 'colour', 'legs', 'discovered', and 'fun_facts' end up as keys in the HSTORE > and the values are strings, integers, dates and lists on the python side but > stored as strings in the HSTORE such a way that they can be CAST-ed in a > server query [where possible]: > > session().query(Animal).filter(Animal.legs > 2) > > and get a query like > > SELECT ... FROM animal WHERE CAST(animal.data -> legs AS INTEGER) > 2 > > You can also put an arbitrary JSONEncodable object in there too. Collections > get converted to Mutable counterparts for change-tracking. > > In many ways it is similar to ColumnProperty except that - the properties are > writable (and when written only trigger the relevant bits of the hstore to be > updated). Also on object instances the values in HsProperties are fetched as > part of the query; we lazily de-serialise them directly from the hstore > dictionary. > > Before spend a couple of days removing our corporate clutter from that, > getting permission to license it etc.. and posting either as a patch or > extension I thought I would see if there is any interest (or if someone has > already done it better?). It's implemented as a custom metaclass right now, > but I think I might be able to do it fully with events. that’s a very nice pattern! It looks like you could do that strictly with Python descriptors, such as subclassing @hybrid_property, no ? Each property is just an expression against the “data” column, either python-side (lazily deserialize a key) or expression-side (do a postgresql expression for a certain key), and you can also trigger the mutable.is_changed() flag within the setter. I don’t think you’d need events. > > Code aside, if you can think of ways in which we as a company could support > SQLAlchemy (bear in mind I am not in charge of the purse strings, but I can > make a pitch on your behalf; we are still awaiting the fruits of our donation > to the PyPy guys :).** Then do let me know. I don't check this email account > all that regularly but my work address is my firstname.lastname at > cantabcapital dot com Thanks ! I think what I’m usually looking for are people resources. Doc fixes and pull requests and such. If I could organize some significant batch of work as something that would work under a “grant” model, I’ll let you know. I haven’t figured out how to work that way, yet.
signature.asc
Description: Message signed with OpenPGP using GPGMail
