I think list:integer should take advantage of postgres list feature if available. The issue is how to make it backward compatible to current implementation.
On Tuesday, 5 June 2012 15:33:37 UTC-5, mcm wrote: > > Wouldn't that make it non portable to other db's? > > mic > > > 2012/6/5 Bruno Rocha <[email protected]>: > > Cant we have a custom field for this? > > > > Field.PostgresIntegerList("name") > > > > http://zerp.ly/rochacbruno > > > > Em 02/06/2012 00:26, "Massimo Di Pierro" <[email protected]> > > escreveu: > > > >> The search by content should be faster using native postgresql array > type. > >> Everything else should be the same. We could change it and should be > easy. > >> The problem is backward compatibility. I need to give some thought > about > >> this. Please open a ticket to google code. > >> > >> On Friday, 1 June 2012 16:49:39 UTC-5, Lewis wrote: > >>> > >>> By any chance is the DAL list:integer type implemented as a postgresql > >>> array? The web2py book would say no--the list:integer is a big text > field > >>> as '1 | 2 | 3', etc. > >>> > >>> Could it be implemented using postgresql's native array types in the > DAL > >>> driver for postgresql? I'd assume that optimized db query code would > be > >>> rather faster than parsing a big text field in python code. > >>> > >>> How could I code a model with a FIELD function that referred to a > >>> postgresql array field ('CREATE TABLE foo (favorites integer[], more > >>> fields...);') that I created outside of the DAL? I am thinking this > is not > >>> possible as the DAL types could not map to this postgresql type to > express > >>> queries and handle results. > >>> > >>> Assuming I end up using Field('favorites', 'list:integer') what are > the > >>> performance implications? > >>> > >>> My usage is that each user can have favorites, which will simply be > the > >>> numeric key of the favorite item. A favorites table would have three > >>> fields: id (as key), user (refer to auth.user.id), favorites (a list > or > >>> array of integers). > >>> > >>> Thanks for any suggestions/comments. > >>> > >>> - Lewis >
