From: Luke O. <lu...@me...> - 2003-04-25 22:10:43
|
Hey all - Ok, I'm going to present a possibly controversial idea. I'd like to propose the concept of 'temporary' objects, for use in cases where you want to save values (say from a series of web forms) in SQLObject-constrained containers (columns, relationships), but don't want to persist to the database until the user finishes the process. Two use cases: 1. Creating a new temp object, modifying etc, eventually persisting to a real SQLObject. 2. Taking an existing SQLObject, creating a temp from it, modifying etc, and storing back to the original record. Hardest part of this: dealing with foreignKeys, on persist keys have to be updated from their fake values to the actual new objects' ids. Not sure whether to implement this as a helper class to SQLObject (that takes an SQLObject on init), or directly in SQLObject. Examples: Helper class ------------ x = TempSQLObject.new(Person,....) #just like SQLOBject.new(....) x.whatever ... y = x.persist() # y is now a real SQLObject of type Person. z = Person(23) # existing object w = TempSQLObject(z) .... z = w.persist() Part of SQLObject ----------------- x = Person.temp(.....) # just like .new() .... x.persist() # no possibility of keeping temp object; it's real now. y = Person(23) w = y.temp() .... y.persist(w) # or y.set(w) ? Any thoughts? My immediate preference is to do it as part of SQLObject, it would be very similar to the _SO_autoInitDone flags. But makes a rather substantial change to the class for something that other people may not need. The TempSQLObject direction keeps more separation, but makes interface maintenance more difficult (in my mind so far). Enjoy, Luke |