On Mar 26, 6:02 pm, "Gabriel Genellina" <[EMAIL PROTECTED]> wrote: > En Wed, 26 Mar 2008 18:01:31 -0300, George Sakkis > <[EMAIL PROTECTED]> escribió: > > > On Mar 26, 3:41 pm, Tim Henderson <[EMAIL PROTECTED]> wrote: > > >> I am using mysql, and sqlite is not appropriate for my situation since > >> some of the databases and tables I access are being accessed by other > >> applications which are already written and live. I am not using the > >> SQLAlchemy or SQLObject, because I didn't want too (although in the > >> future I may consider using them). > > > I'd strongly second looking into SQLAlchemy; from what you wrote, I > > suspect sooner or later you'll end up creating (to paraphrase > > Greenspun) an ad hoc, informally-specified, bug-ridden, slow > > implementation of half of SQLAlchemy. > > You beat me to say that, but using SQLObject instead. > Moreover, the OP is looking for the PersistentDict and PersistentList > classes that ZODB uses. > I'm not sure that triggering a database write for each and every modified > attribute is a good thing; I'd use a "dirty" flag instead (ZODB uses > _p_changed) and write all modifications at the end. > Since not all methods modify the object contents, using a metaclass to > flag all of them isn't a good idea either. I'd use a decorator; after all, > they're not so many methods; if you inherit from DictMixin you only have > to write __getitem__, __setitem__, __delitem__ and keys(), and of those, > only __setitem__ and __delitem__ modify the object.
That depends on technology: in volatile memory, persistence is a long- term commitment. In static-state memory, it's a norm. Say you've got a flash drive on the bus, you could store the objects themselves: the Python module would have to allocate from the ROM, reobtain later. Don't store the interpreter on the ROM, and trade-off feature sets for expiration date. But standards expire? -- http://mail.python.org/mailman/listinfo/python-list
