Re: [Zope] Using "Session" to store per-session data.
Alexander Staubo wrote In my opinion it's getting increasingly obvious that the ZODB badly needs cheap, non-undoable, "transient" transactions.
<aol>me too</aol>
Counters, sessions, often-refreshed internal state tables -- lots of applications need it, and moving this stuff outside the ZODB breaks with the object-oriented design.
an alternative would be an object that's backed by an SQL table. change the attributes, it flows through to the table. Anthony.
At 12:52 AM 9/15/99 +1000, Anthony Baxter wrote:
Alexander Staubo wrote Counters, sessions, often-refreshed internal state tables -- lots of applications need it, and moving this stuff outside the ZODB breaks with the object-oriented design.
an alternative would be an object that's backed by an SQL table.
change the attributes, it flows through to the table.
Doesn't even need to be that hard. For counters, create a Counter ZClass, give it SQL methods to set/get the current value, given the counter's ID or absolute path, and maybe add some DTML methods for formatting. No fancy persistence hooks required. For sessions, things are a tad more complex. Either you need a more complicated table structure, or you need to store a pickle. But it's still doable with only minor magicks, no black wizardry required. For all of the above applications, including 'often-refreshed internal state tables', Gadfly probably suffices as a data store unless you have a really high volume site. I can see using GF tables for things like 'who's online right now and where are they in the site' displays, that sort of thing.
participants (2)
-
Anthony Baxter -
Phillip J. Eby