On Tuesday, January 15, 2002, at 12:36 , Troy Farrell wrote:
Mmmm. Good point. Joe, I'd assumed you were storing the data in a python product/class object in the ZODB. Grand. Now I'm second guessing myself.
Joe, can you clarify your architecture a bit? What DB? Are you moving the cgi(s) to a python product? A set of external methods?
I'm writing a job tracking system. It's an extremely simple database - one table with the job specific data, and another for the comments attached to the jobs. I'm using PostgreSQL as the back end, but I don't have a lot of experience with it yet. The current system is a bunch of separate cgis, using a home-brewed framework that frankly, is kind of awkward to deal with in a lot of ways. I sat down to break the code into a more logical layout before adding some more features, and decided it would be worth some time to look for another framework to use before investing too much more time into my homebrewed cgi framework, and discovered Zope. Zope has made my life easier in a lot of ways, but the one nice thing about running each job or comment creation as a separate cgi invocation was making it easy to create unique IDs to use in my inserts. The awkward thing is, when I create a job, I have to simultaneously create a comment to attach to it with information about who initially created the job, and some descriptive data, so I need to know what jobid the job gets so I can add the comment to the comment db with the appropriate jobid identifier. I'm probably missing something in postgresql where I can do an insert and have it return whatever jobid it automatically generates. On the Zope side, I'm using ZPsycoPg as my postgres connection. jpb -- Joe Block <jpb@ApesSeekingKnowledge.net> Benchmarks are like bikinis -- what they reveal may be enticing, but the details that they conceal are crucial.