On Dec 15, 2011, at 1:16 PM, Kent wrote: >> why not use a before_flush() extension, or similarly a >> before_insert/before_update/before_delete extension, and simply reject >> flush() calls which include such objects in the list of those to be modified >> ? The fact is they still represent database data and will work a lot >> better if they have access to their persistent state. > > While I like the sound of this idea, it doesn't deal very well with the > notion of being able to expunge(order) and have everything under its expunge > cascade tree automatically excluded, does it?
I'm suggesting in that particular case that you aren't expunging - your object model would include features such that a flag like "historical" be present on those objects which fall under this category - or some kind of event model outside of SQLAlchemy. If that needs to cascade among collections, you'd have to build that too. This is an object model state/validation issue, not a persistence issue. > If I head this direction, how do I "reject the flush()" for certain instances? You'd iterate through session.dirty inside of before_flush(), check for the correct state, otherwise raise an exception. > >>> My concern is that once such an object has been expunged, I don't want >>> any relationship or code or anything automatically reloading or >>> refreshing it from the database with session.query().get. >> you mean, because that raises an error on a detached , or because the >> objects represent in-memory-only state that should no longer reflect >> database state ? > A while ago (with your help), I already dealt with loading relationships for > transient/expunged based on my use case of always a single session, which > made that framework change workable. So the reason for my concern is the > latter, because it represents a state in memory only. I admit, leaving the > object in the session solves this problem, but creates a new one where I > can't easily utilize the expunge cascade. If I leave it in the session, I > think it also creates a different problem: that I'd need to worry about a > different query overwriting (refreshing) my object with the database contents. OK so if these objects truly become an in-memory state not represented in the DB then yes you'd want to expunge them. In the session means the object is proxied to an actual row in the DB. Out of it, means it is not. >>> s being loaded from the database that I've already expunged. >> if you are going that approach I would just use a library call within your >> own app called "mark_as_historical()", which does the expunge() and also >> adds the element to the collection in question. This is functionality in >> addition to what expunge() does. > I had that thought as well, but it doesn't deal with cascaded expunges. I might cascade the operation myself then.....it seems like you have business logic that requires traversal. Piggybacking off persistence operations that happen to do the same kind of traversal (for now) is brittle. > I could subclass session for this in a non public API way. But I'm becoming > fond of your idea of leaving the objects in the session as you suggested with > before_flush() or _update()... any thoughts on how I could work needing to > avoid backrefs for every relationship in the expunge cascade? Are there > reasons one need to avoid referencing unloaded relationships from within > before_upate()? (I can't recall the exact problem I've had in the past with > that at the moment.) yeah I'm not sure what you mean here, I'd have to look this up in the huge catalog of problems you've had with backrefs.... :) > > Which does your gut tell you is "safer": the expunged approach or the leave > in session but prevent writing changes approach? if they really aren't rows anymore then I'd expunge, but id consider this a separate concern versus management of application state. > > (For what its worth, I've made appeals to my company on more than one > occasion about donating to your project, but with little success so far (I > think because we can't afford to pay all our current employees quite yet), > but we're growing and we'll get there... I would love to have our company > donate to the project, you've always been so helpful. For now, a sincere > "thank you" will have to suffice.. sorry.) You know most donations I get are from people I've never heard of. I get donations from active mailing list folks too but not as much, but don't worry just the back and forth on all the backref/Oracle tickets we've worked on have been a great contribution from you, leading to a better product and therefore more contributions from other folks who didn't have to go through all that! -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected]. 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.
