Hey Joe. I think your heebie-jeebies are well placed. They eat up memory, and cause problems when trying to share sessions across a number of servers. But then it's just so EASY!
I think that Reactor's alias is similar to Hibernate's table-per- class / discriminator system. We'll see. I think that I am going to continue on the session path for this app and perhaps look at a DBed solution in the future. -Brian On Jan 24, 12:15 am, Joe Bodell <[email protected]> wrote: > Yeah, you definitely have some options with a DB-persistent model -- a > different table for WIP data would solve the issue, but then you have to > make sure you remove it once it's ready to go to the "real" table. In > Reactor, aliasing a single table so one "entity" can be the WIP and the > other can be the "real" is easy, but I'll admit that I haven't had much > opportunity to play with the baked-in ORM in CF9, so I don't know how that > would shake out code-wise. I prefer something more persistent than the > session, if only because using the session for things other than scalar > datatypes gives me the heebie-jeebies. But that's probably more a personal > preference thing than anything :-) > > > > > > > > On Mon, Jan 23, 2012 at 10:40 PM, Brian H. <[email protected]> wrote: > > @Brian, good to know that my method isn't off the wall : ) Thanks > > for instilling me with confidence. > > > @Joe, Since the object would be in an invalid state until the end of > > the wizard, I did not want to persist the object to it's regular > > table. You are suggesting that I store in-progress entities in a > > different table? I'm not even sure how to convince ORM to do that. > > Unless I created a new entity type just for the WIP, and then copy it > > over to the real entity, save the real entity, then delete the WIP. If > > I was good, I might try to make use of Table-Per-Class and define the > > two entites Entity, and EntityWIP, and they would technically share > > the same table, but the EntityWIP would have it's validation disabled, > > and ORM's TPC/discriminator would naturally filter out the WIP > > entities from all getEntity calls. Slick. Not sure of the gotchas. > > > I like storing the in-progress entity in the session since session > > handling will automatically clean up that memory space. I do -NOT- > > like storing the entity in the session because then it makes > > clustering all that much more difficult in the future. Choices... > > > Thanks guys. > > > -Brian > > > On Jan 23, 9:39 am, Joe Bodell <[email protected]> wrote: > > > Is it out of the question to persist the object in the database? It is an > > > ORM object, after all, but it seems like there's a tradeoff between the > > > time it takes to update an "in-progress" record on a few requests in a > > > sequence and the time it takes to persist the entire ORM object in the > > > session scope. If you write the in-progress data to a table that looks > > like > > > the "complete" data but has a different key, then all you need to persist > > > in the event args is the key value on the in-progress record, and an > > event > > > redirect including that ID will cover you. > > > > Just a thought... > > > > --Joe > > > > On Fri, Jan 20, 2012 at 11:43 PM, Brian H. <[email protected]> wrote: > > > > It has been a couple of years since I've last tackled this request so > > > > I would like to see if such a feature has been added to M2 before I > > > > roll my own. > > > > > I have to implement a multiple-step wizard, setting properties in an > > > > ORM object across multiple requests until a confirm screen, and then a > > > > final orm save to the database. > > > > > How I've accomplished this in the past was to roll a small session > > > > persistence system into my session facade: > > > > > persistID = sessionFacade.persist(object) > > > > object = sessionFacade.getPersisted(persistID) > > > > > Then I have a M2 plugin which watches the event scope, and if it finds > > > > an event-arg named "persistId" then it will automatically pull the > > > > object with that ID into the event scope with the object's original > > > > name. The persistID is just a hidden field passed between form posts. > > > > > Not the most complex solution, and it works, but wondering what else > > > > people are doing to solve this requirement. I know the M2 has redirect > > > > level persistence, but I am not doing a redirect. > > > > > Thanks for the input! > > > > > -Brian > > > > > -- > > > > To post to this group, send email to > > > > [email protected] > > > > For more options and to unsubscribe, visit this group at > > > >http://groups.google.com/group/mach-ii-for-coldfusion?hl=en > > > > > SVN:http://svn.mach-ii.com/machii/ > > > > Wiki / Documentation / Tickets:http://trac.mach-ii.com/machii/ > > > -- > > To post to this group, send email to > > [email protected] > > For more options and to unsubscribe, visit this group at > >http://groups.google.com/group/mach-ii-for-coldfusion?hl=en > > > SVN:http://svn.mach-ii.com/machii/ > > Wiki / Documentation / Tickets:http://trac.mach-ii.com/machii/ -- To post to this group, send email to [email protected] For more options and to unsubscribe, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en SVN: http://svn.mach-ii.com/machii/ Wiki / Documentation / Tickets: http://trac.mach-ii.com/machii/
