[EMAIL PROTECTED] wrote:
> 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
