3 Aug 2009 15:46
How does storm handle dependencies for DELETEs?
I've been working on the following class for some of our integration
tests (these are the relevant parts):
class RowTracker(object):
def __init__(self, store):
self.store = store
self.tracked_objs = []
def track(self, obj):
if obj not in self.tracked_objs:
self.tracked_objs.append(obj)
def add(self, obj):
self.store.add(obj)
self.track(obj)
def revert(self):
self.tracked_objs.reverse()
for obj in self.tracked_objs:
self.store.remove(obj)
try:
self.store.commit()
except:
print "++++ exception on reverting changes ++++"
print "Tracked objects: %s" % self.tracked_objs
raise
self.tracked_objs = []
The idea being that when I add an object to it, it will be created in
the database. When I call the revert method, the objects should be
(Continue reading)
I'm fishing for ideas on how to get one that doesn't behave
> poorly, or at least better than my first experiment. It may be
> impossible.
Perhaps it would be possible to implement some kind of profiling cache
implementation would be worthwhile then: something that would record
cache hits and misses, and some utilities to analyse that data.
> I do feel that if I had a half decent implementation and could tell a
> program 'Use up to 2GB of RAM', that would be useful for almost all of
> the code we deploy. Our current mechanism is to make an educated guess
> as to the cache size and forget about it unless performance or RAM
> consumption is an issue (multiple bits of code sharing a server means
> swapping is bad). Even if went to the trouble of calculating the ideal
> cache size, soon it would no longer be ideal as our data is constantly
> changing - the optimal cache size for importing a pofile with small
RSS Feed