Thread: [SQLObject] Non-DB SQLObject instances
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Jeff W. <je...@me...> - 2005-10-07 12:45:38
|
I've been taking on the challenge of building an identity management and access control framework for TurboGears. One of the features I really liked about working with BroadVision's Web framework (back in 2001) was the notion of an anonymous visitor. During the course of a visit, you could collect various information about the visitor (name, age, etc) and populate the anonymous visitor record. Then if the visitor asked, you could stash that in the DB. I'd like to do the same (or similar) thing with TurboGears and SQLObject. However, I don't seem to be able to create an instance of SQLObject that *isn't* created in the database. Does anyone have any suggestions? -- Jeff Watkins http://metrocat.org/ Democracy n: A country where the newspapers are pro-American. |
From: Oleg B. <ph...@ma...> - 2005-10-07 13:18:22
|
On Fri, Oct 07, 2005 at 08:44:21AM -0400, Jeff Watkins wrote: > I don't seem to be able to create an instance of > SQLObject that *isn't* created in the database. But of course! It is SQL Object. It maps SQL unto Python, see? How you can you create a non-DB object in SQL? The same way it can be done with SQLObject! Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Jeff W. <je...@me...> - 2005-10-07 14:11:55
|
Oleg Broytmann wrote: >>I don't seem to be able to create an instance of >>SQLObject that *isn't* created in the database. > > > But of course! It is SQL Object. It maps SQL unto Python, see? How you > can you create a non-DB object in SQL? The same way it can be done with > SQLObject! Oleg, thanks for responding, however, I hope we can all see the value of an object that hasn't been inserted into the DB *yet*. I suppose this ties back into the notion of lazy inserts, but it's becoming increasingly important to my project. Were I better versed in Python and had more experience with SQLObject, I might consider adding this functionality to SQLObject. Although I know it's no small task, I think it's vital. Jeff -- Jeff Watkins http://metrocat.org/ |
From: Kevin D. <da...@gm...> - 2005-10-07 15:12:18
|
On 10/7/05, Jeff Watkins <je...@me...> wrote: > Were I better versed in Python and had more experience with SQLObject, I > might consider adding this functionality to SQLObject. Although I know > it's no small task, I think it's vital. I agree with you. I've also wanted to be able to create these objects before I was ready to insert into the database. lazy creation would be a good thing. You can, until then, create a dict with the information and then use that to later instantiate an object. The only drawback, of course, is that a dict is a dumb data container which doesn't have any methods. Kevin |
From: Oleg B. <ph...@ph...> - 2005-10-07 15:29:21
|
On Fri, Oct 07, 2005 at 11:12:17AM -0400, Kevin Dangoor wrote: > You can, until then, create a dict with the information and then use > that to later instantiate an object. The only drawback, of course, is That's my advice, too. > that a dict is a dumb data container which doesn't have any methods. What methods should have a non-DB SQLObject? Data attributes? That can easily be emulated. When would you want to put it into the DB? Why not just do MyTable(**mydict) at that time instead? Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Jorge G. <go...@ie...> - 2005-10-07 18:16:40
|
Jeff Watkins <je...@me...> writes: > Oleg, thanks for responding, however, I hope we can all see the value of an > object that hasn't been inserted into the DB *yet*. I suppose this ties back > into the notion of lazy inserts, but it's becoming increasingly important to > my project. I'd rather say that it has not been *commited* yet. It may have started an insertion transaction and the "I want to be in your database" button just commits the transaction. If the user goes away, it is rolled back and that's it. > Were I better versed in Python and had more experience with SQLObject, I might > consider adding this functionality to SQLObject. Although I know it's no small > task, I think it's vital. Even with transactions? -- Jorge Godoy <go...@ie...> |
From: Ian B. <ia...@co...> - 2005-10-07 15:54:51
|
Jeff Watkins wrote: > I've been taking on the challenge of building an identity management and > access control framework for TurboGears. One of the features I really > liked about working with BroadVision's Web framework (back in 2001) was > the notion of an anonymous visitor. > > During the course of a visit, you could collect various information > about the visitor (name, age, etc) and populate the anonymous visitor > record. Then if the visitor asked, you could stash that in the DB. > > I'd like to do the same (or similar) thing with TurboGears and > SQLObject. However, I don't seem to be able to create an instance of > SQLObject that *isn't* created in the database. > > Does anyone have any suggestions? Well, you can't do that. I can basically understand the idea, though I've had very little motivation to do this in my own work. Technically it's rather subtle; as I've said before, I'd have to see a really detailed proposal to really be able to consider what it'd mean for the code. Unit tests make for a particularly good proposal format. But anyway, when I've created out-of-database objects to represent future persistence (like a shopping cart representing a future invoice, or an anonymous user, or whatever) I've later regretted it, and decided that I should have just put it in the database from the beginning. After all, you still have to give the user an ID -- even a random and temporary one -- because you have to associate the user with their future requests. And you'll still need to do cleanup, as those anonymous users won't go away on their own. Doing it in the database isn't so bad. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Jeff W. <je...@me...> - 2005-10-07 18:26:07
|
> I'd rather say that it has not been *commited* yet. It may have started an > insertion transaction and the "I want to be in your database" button just > commits the transaction. If the user goes away, it is rolled back and that's > it. Nope. This object lives across numerous pages. There may be many transactions begun and committed before I decide whether to create a DB object from the memory version. Furthermore, given the stateless nature of the Web, I have no way of knowing whether the object was abandoned -- therefore, no way to know whether to rollback the database changes. Support for transactions really doesn't alter the equation. Jeff -- Jeff Watkins http://metrocat.org/ |
From: Jorge G. <go...@ie...> - 2005-10-07 18:47:13
|
Jeff Watkins <je...@me...> writes: > Nope. This object lives across numerous pages. There may be many transactions What's the problem with it living across pages? > begun and committed before I decide whether to create a DB object from the > memory version. Furthermore, given the stateless nature of the Web, I have no So you're saying that you'd rather not have simultaneous transactions? 'Cause I see no problem with that. > way of knowing whether the object was abandoned -- You can put a TTL to it. Or your database can do that for you automatically... > therefore, no way to know whether to rollback the database changes. How's that? If you don't commit, you rollback. Depending on your model and database you can put a lot of things inside the same initial transaction and later, when the user returns, you can make lots of smaller transactions to optimize the process. > Support for transactions really doesn't alter the equation. So yu had this analisys done. :-) I'm not familiar with the problem, but I would think on DB persistence and cleanup routines (some kind of "dirt flag", at least, that is cleared when the user press the button is an alternative, modeling that with triggers and cascading deletions could clean up your database if there's no confirmation in, lets say, 2h...). Be seeing you, -- Jorge Godoy <go...@ie...> |
From: Bob I. <bo...@re...> - 2005-10-07 19:03:03
|
On Oct 7, 2005, at 11:25 AM, Jeff Watkins wrote: >> I'd rather say that it has not been *commited* yet. It may have >> started an >> insertion transaction and the "I want to be in your database" >> button just >> commits the transaction. If the user goes away, it is rolled back >> and that's >> it. >> > > Nope. This object lives across numerous pages. There may be many > transactions begun and committed before I decide whether to create > a DB object from the memory version. Furthermore, given the > stateless nature of the Web, I have no way of knowing whether the > object was abandoned -- therefore, no way to know whether to > rollback the database changes. > > Support for transactions really doesn't alter the equation. If the object lives longer than a page view, and isn't entirely stored in client-side post data or a cookie, put it in the database. Doing anything else is just silly. -bob |
From: Oleg B. <ph...@ma...> - 2005-10-07 20:00:19
|
On Fri, Oct 07, 2005 at 12:02:52PM -0700, Bob Ippolito wrote: > If the object lives longer than a page view, and isn't entirely > stored in client-side post data or a cookie, put it in the database. > Doing anything else is just silly. Silly or not silly - it just wouldn't work. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Tim L. <tl...@gm...> - 2005-10-08 23:23:29
|
> > I'd rather say that it has not been *commited* yet. It may have starte= d an > > insertion transaction and the "I want to be in your database" button ju= st > > commits the transaction. If the user goes away, it is rolled back and = that's > > it. > > Nope. This object lives across numerous pages. There may be many > transactions begun and committed before I decide whether to create a DB > object from the memory version. Furthermore, given the stateless nature > of the Web, I have no way of knowing whether the object was abandoned -- > therefore, no way to know whether to rollback the database changes. I have the same problem; I've opted to defer object creation until the last page. It's not a big issue for me, though, because I _can't_ create it as an object until later--it wouldn't meet the schema constraints (nonNull columns, etc.) until the last step. It's much easier to persist earlier steps as hidden input fields in the intermediate forms. -- Tim Lesher <tl...@gm...> |