> @Mark, yeah I saw in the notes that the cache was your main obstacle, > I've not really used the cache very extensively so don't really have > any suggestions as to how that one can be solved, I mean, when you say > 'Where it all gets tricky is if you want to pull back the object in > after being deleted' what do you mean by this, are we actually > changing the state of the object from deleted to live again? or we > just want to retrieve the deleted objects? I mean, perhaps 'deleted' > is the wrong term here, perhaps we should be calling them 'archived' > objects or something.
Doesn't really matter what you call them - the issue is the cache and the compositions that object is involved in. a) if something is in the cache, it is deemed persisted. Regardless of whether or not you use real, or soft delete, that is pretty much the case. b) If you return an object back to 'persisted' state, after being deleted, you will need to notify any composition it COULD have been in - hey, you may need to add this object. This is tricky (not impossible, just tricky). c) If you just want to retrieve the deleted object, and look at it - you have to make sure IT's compositions work in the cache, but that those of live objects don't... or maybe the deleted object doesn't get cached, but we need to make sure that doesn't corrupt the live cache... > > Can objects not just be loaded back into the cache in the same way as > a new object being created? Again, it's an issue of composition. > > I also see that you talk about the fact that we'd still have to > include the filter options in the TQL to save it pulling deleted > objects from the DB, this is no real biggy but again it all detracts > from the idea of the ORM having it as a native feature, The > implementation from my point of view would in an ideal world be > seamless, I'd query and delete objects in the same fashion as I do now > but Transfer would handle the rest, if I've still got to concern > myself with asking the ORM not to pull deleted records then I might as > well go to the effort of overwriting the delete methods with update > myself and not have the feature in the ORM? Yeah, that is why it would be nice if Transfer handled it natively. > > With that said; there are always situations where I DO want to pull > deleted objects, this should be specifiable in the TQL and override > the default setting of it not pulling deleted records, you almost need > to make 'achived' or 'deleted' a nonsettable property on the object > which is controlled solely by the ORM, then in my TQL is assumes I > only ever want objects Achived = False but if needs be I can specify > Archived = True and get my hands on them. > > Another quickie; with regards to the conditions on the collections, > how does that work? this involves CF doing the leg work of not giving > back the deleted records, correct? My only concern with that would be > that in busy application where we have high-turnover of objects the > number of deleted records becomes by quite a stretch the more dominant > count of objects and yet they're seldom used by the end user and it > seems a shame to be eating up all my cache space and have CF chug > through the collection all the time when really the deleted records > should be sat in the DB until they're required. Not sure what you mean by 'how does this work'? You mean conditions in general - http://docs.transfer-orm.com/wiki/Transfer_Configuration_File.cfm#onetomany has some documentation on it. > > This is a good discussion guys, thanks a great deal for all the > suggestions that are flying around :-) Apologies if I'm a little slow > on the uptake for some of them, I've been working ORM free for the > past few months ;-) > > Rob >-- E: mark.man...@gmail.com W: www.compoundtheory.com --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to transfer-dev-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
