On 4/19/06, Asheesh Laroia <[EMAIL PROTECTED]> wrote: > On Wed, 19 Apr 2006, Elver Loho wrote: > > > On 4/19/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote: > >> On Wed, Apr 19, 2006 at 05:24:56PM +0300, Elver Loho wrote: > >>> class Transactions(SQLObject): > >>> sqlmeta.fromDatabase = True > >>> > >>> AttributeError: No connection has been defined for this thread or process > >> > >> You asked SQLObject to draw the definition for the table from the > >> DB. SQLObject honestly tried to do exactly that and failed because it > >> cannot connect to the DB. > >> Initialize a connection before manipulating with the DB; setting > >> sqlmeta.fromDatabase = True is a manipulation... > > > > I want to have a class that is initialised from the database. I also > > want to put its definition in the same file or include the model just > > once into my program. However, this is impossible as far as I know. Or > > is it? > > To clarify what you want, is it that you want to define define > sqlmeta.fromDatabase to be true and have the class not fetch its > attributes from the database until the class is *used*, rather than when > the class is *defined*? It appears that the latter is the current > behavior.
Yes. Exactly. Right now I've got one app with a class that imports tables from my model at the beginning of almost every method. This is very annoying. > (Also, your tone is borderline flaming and certainly not respectful. > Please calm down and help work toward constructive solutions.) SQLObject is useful and the idea is great, but some of its limitations seem downright moronic at times. Hence, the frustration. I can define an SQLObject-derived class by hand and place it at the beginning of my file. Awesome. I *can't* do the same when I want the class to be based on an actual table in the database. This inconsistency makes no sense. And what's with demanding that every table have an "id" field? I want to use SQLObject with old, legacy databases. Like right now I'm working with a webstore database where the Transactions table's primary key is an 11-letter varchar named "code". I don't see *any* point to enforcing that it be named "id" and it be of type integer. With PyGTK and SQLObject I recently built a translation GUI for our webstore. Hacking around SQLObject's limitations was a real pain in the butt. Among other things I had to add an 'id' field to an existing database just because SQLObject can't live without it. Sure, SQLObject is mondo awesome when you're building a new system from scratch. However, it plain sucks when you try to use it with existing databases. This situation itself meta-sucks, because there really aren't any better alternatives out there. Sigh. Elver ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ sqlobject-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
