On Monday, December 20, 2010 12:12:12 pm marcelo nicolet wrote:
> On 12/20/2010 05:03 PM, John Fabiani wrote:
> > On Monday, December 20, 2010 11:49:02 am marcelo nicolet wrote:
> >> Thank you, Ed.
> >> In fact, I was reading about the internals of psycopg and the module
> >> interprets python lists as postgres arrays and the other way.
> >> The only thing I would need, then, is to "present" that list to dabo as
> >> discrete values.
> >> Where is the appropriate place to do that?
> >> TIA
> >>
> >> On 12/20/2010 04:09 PM, Ed Leafe wrote:
> >>> On Dec 19, 2010, at 5:39 PM, marcelo nicolet wrote:
> >>>> But it would be nice to take advantage of the arrays this engine
> >>>> supports. In fact, the business model of the project focuses on a
> >>>> vector of integers, which is very inconvenient to manage in true
> >>>> normalized form, and also as a set of scalars in the same relation.
> >>>> So, I am asking for an example of how to integrate non standard types
> >>>> from the backend into dabo.
> >>>>
> >>> I would assume that you would have to create custom handlers for
these
> >>> data types. I would imagine that psycopg would make the necessary
> >>> conversion from the PostegreSQL datatype to the nearest Python type
> >>> (list in this case). I'm not sure how Dabo would handle lists as
> >>> column values, as I've never tried anything like that. However, if
> >>> you do try and get errors at the Dabo level, please paste the
> >>> tracebacks here so that we can see what would have to be improved in
> >>> order to handle these correctly.
> >>>
> >>> -- Ed Leafe
> >
> > I have several questions
> > Is each of the array fields fixed in the number of elements?
> > Is each element with in the array the same data type?
> > Are you going to search on any of the elements?
> > Will you be adding elements to the array?
> >
> >
> > Johnf
>
> Yes, they are of fixed size; all elements are integers (in this case, of
> course). The arrays will not change in size once stored.
> Regarding query, the arrays will be retrieved always in their entirety;
> if the user request some filtering, it will be done programatically, not
> at the backend level.
Untested and just things I'd try first:
First I believe the dbPostgres.py will return '?' as the datatype but the
field name should be there. So it might be possible to use the standard
createBizobj() routine to create the bizobj. Therefore, you could use a
virtual field routine to populate the added fields. Of course you then need
to handle the save (I think you will no matter what you do).
Something like;
self.VirtualFields = {'listitem1':self.getItem_1, 'listitem2':self.getitem_2,
...}
def getitem_1(self):
listitems = self.Record.fieldname
return listitems[0]
A second way would be to create a DataSource (manual define). The write the
method to retrieve the data and populate the DataSource/DataSet.
Once the data is in a bizobj it should lend it self to all the filtering
required.
Then over write the bizob's save routine to populate the array. Rebuild the
list and pass it to psycopg.
I try my hardest to always get everything into a DataSource first. That way I
can work within the Dabo framework and use all the tools.
I will not say I haven't gone way outside of Dabo to get the job done because
I have. But I call that the 'dark side' and it's always better to work with
the force Luke!
Johnf
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message:
http://leafe.com/archives/byMID/[email protected]
