Ian wrote:
>I'm starting to realize that I'm mirroring MK in many ways :) If it >hadn't been for the CSV database descriptions, maybe I'd never have come >this direction... well, I prefer my style of instantiation as well, but >again, it's probably a more aesthetic than structural distinction. I know what you mean... MK is very pleasant, and very complete in many ways. I just can't use it (or any other alternative I've looked at) since my application will need to be portable across RDBMS systems. Even worse, it needs to use data from more than one RDBMS system at the same time, and the potentially voluminous data is in the usual 3-4NF. I.e., I don't have a closed-world environment where I can control the RDBMS or even the schema used. >The code I wrote recently is at: > >http://www.colorstudy.net/software/webware/DBWrapper-0.0.tar.gz OK, thanks--I'll take a look at it. Always trying to find better/simpler ways to do things! >How do you add extra methods to your results? For instance, I keep >extra information associated with a row in files quite often -- for >instance, image files which are inefficient to store in the database. >However, I'd like to treat that extra information the same way I treat >the in-DB information. All the wrappers that use dictionary-like access >bugged me because they made me make that distinction explicitly in the >API. I have higher level objects for this. The code that I've been discussing up until now has been just to provide some level of abstraction away from raw SQL. The higher level objects have predefined attributes drawn from RDBMS tables. Users can add new attributes (like the name of an external file) to the instance. When the instance is suspended (not deleted), the extra attributes get pickled and stored. New, unbound methods are defined and stored in tables. When it comes time to use them, the higher level object looks them up and execs them. This is not safe, but the only way I can think of for hooking in yet-to-be-defined methods into live objects (apart from using mix-ins, I suppose). Anyway, the only people who can add new methods are programmers, and they can do anything anyway. An alternative I'm toying with is to keep a library of unbound function objects floating around, and pass them in to other objects for execution as needed. Haven't had time to think through this yet. >Maybe it's that I started programming in functional languages, or that I >like the set-like analogies in an RDBMS, but I can't stand stateful >APIs, especially with databases -- ADO is like this, as I remember, as >well as DBAPI and others. I just don't understand why you'd want to do >it that way -- perhaps if you have another object, like a >selection/querying object, which holds this state separate from the >connection. So, if you have a connection object conn, you might do: Actually, the only reason I'm doing it this way is to simplify the functional interface: sel.rows(where="id=1 and name='apple'", columnList=['col_one', 'col_two'] Becomes: sel.rows.columnList = ['col_one', 'col_two'] sel.rows(id=1, name='apple') Basically, I use **parms to pick up the selection criteria. It also makes it easier to form the SQL since I can then rely on the DB API to do the type conversions for me. Hmmm... you just gave me an idea of how to make everything functional again: sel.rows(columnList=['col_one', 'col_two'], id=1, name='apple') and .rows() is then: def rows(columnList=None, **parms): Now, it becomes possible to differentiate between criteria and column selection. I wonder however, if this is more confusing to the API user? ...Edmund. _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
