Dear Greg, I think, I'm repeating all your work, as I didn't find a PostgreSQL-Adaptor for MiddleKit. So we should decide, and simply post patches to whatever we need.
As there are now 4 different python-DB-API 2.0 modules (PyGreSQL, PoPy, PsycoPg and pyPgSQL), perhaps we can try to import all of these in any sequence and do some type of abstraction, so it can use the first it finds. As I'm developing on a W2K machine, the only compiled one I have is pyPgSQL. In the sense of database abstraction, I think it would be best to convert all data to native Python types, to be absolute database independent. Although, this might slow down the system. Where can I see the code of yout PgSQL? Is is free? Could it be integrated into standard Webware distribution? Actually, I convert all the values to python-types. I put a hook in SQLObjectStore which is called after fetchall(). I don't mind that ObjectRefs are of type long, but perhaps should be abstracted to type ObjRefType or something like that. (I think in python 2.2 you can do something like 'class ObjRef(long)' or 'class ObjRefType(types.LongType)'. Greetings, Erny > > Hi all, > > > > with the pyPgSQL some values are not returned as basic Python types. For Postgres >'bigint' I get a PgInt8 type. > > > > Hi, > > Its been a very long time, but I was the one who wrote this code. Here is > the discussion that I had with Chuck at the time: > > > > > > > > At 11:57 PM 7/26/2001 -0700, Greg Brauer wrote: > > > -----Original Message----- > From: Chuck Esterbrook <[EMAIL PROTECTED]> > Date: Thu, 26 Jul 2001 23:33:40 -0400 > Subject: Re: Think I've got it. > > > At 07:54 PM 7/26/2001 -0700, Gregory Brauer wrote: > > >In otherwords, internally were always storing as Pg types. You had > > >mentioned that a PgInt8 would be better than a long, memory wise, > > >and had suggested using that as the internal storage mechanism. > > >To be consistent then, a boolean would be the same. Do you think > > I'm > > >on the right track here? > > > > Basically and this obviously works. But then I'm wondering if this > > will > > affect the portability of MK code. Like if I switch my database from > > Postgres to MySQL to something else, will this approach make it more > > likely > > for things to break? > > > > I'm leaning towards sticking with ordinary Python ints and longs for > > this > > reason. > > Ok, here's another factor. An ObjRef is hard coded in SQLObjectStore > to be a long. So, I can't store references internally as an PGInt8, > which is how they come out of the database. So now I'm faced with > either > > a) overriding a major part of SQLObjectStore in PgSQLObjectStore, > > b) having ObjRefs be converted to Python native types, while Bools > and Longs are Pg types, or > > c) converting all Pg Types to Python types across the board. > > What are your thoughts? > > I prefer (c) for bona fide Python values like bools and ints, but an obj ref > that is a "long" really isn't about Python, it's about internal MK > implementation. Looking at SQLObjectStore, it looks like the hard coding is > the assertion in fetchObjRef(). We could change that to: > > assert type(value) in self.joinedObjRefTypes() > > def joinedObjRefTypes(self): > return (types.LongType,) > > Then a subclass could override the method to return a tuple with more elements. > > There are also the funcs objRefJoin() and objRefSplit(), but since they use > numerical operators, I don't think there should be interference with PgInt8. > > So in summary, my thoughts are, > - convert all data (bool, int, long, float) to Pythonic data > - let "joined" obj ref values be as efficient as they can be, which > in this case would be a PgInt8 > > > -Chuck > > > > > > > > And I'm pretty sure I did what was recommended here, so that is why a PgInt8 > remains so... because it is most typically used to describe an obj ref. > > It's been 6 months since I looked at this code, so I appologize in advance > if I'm wrong about something here. > > Greg > > _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
