new in trunk list:reference

[mdipierro]

Experimentally there is a new feature in trunk.

Field('name','list:string')
Field('name','list:integer')
Field('name','list:reference other table')

and new operators

db.mytable.myfield.contains(4)

which works for list:reference, list:integer, list:string, string and
text types.

The list: type are mapped differently on RDBS ([1,2,3]->'|1|2|3|') and
on GAE (uses a string list propery). It is backward compatible with
data stored using the IS_IN_DB(...,multiple=True). So here is an
example of a program:

# model
db.define_table('product',Field('name'),format='%(name)s')
db.define_table('purchase',Field('code'),Field('products','list:reference
product'))

# controller
def products():
db.product.id.represent=lambda id: A('click
me',_href=URL('purchases_by_product',args=id))
return
dict(form=crud.create(db.product),items=db(db.product.id>0).select())
def purchases():
return
dict(form=crud.create(db.purchase),items=db(db.purchase.id>0).select())
def purchases_by_product():
product_id=request.args(0)
return
dict(items=db(db.purchase.products.contains(product_id)).select())

Now register some products. When you try register purchases you should
automatically get a SELECT window with product names. The list of
items should also show a comma separated list of product names.

I have not tested this on GAE. I could use some tests. Please let me
know.

Massimo

[mdipierro]

There was a problem with this which is now fixed.
This is a very important feature if you plan to develop locally
(sqlite) and deploy on GAE.

Massimo

[Jason Brower]

Should i worry about this on my setups with sqlite but i do not use gae?
Almost all my setups are sqlite but on apachi fcgi.
Best regards,
jason

[mdipierro]

Yes, if you use any validator IS_IN_SET or IS_IN_DB with
multiple=True

I think it is still very convenient and can simplify some of your
code. Yet on RDBS you can do joins and this should be used a
replacement for that.

[Thadeus Burgess]

ew

jaywalking should never be a replacement for joins...

--
Thadeus

[mdipierro]

True but joins are expensive.

If I only need many2many in one directions I use the list:reference
and I cache the query that maps the id into the representation of the
corresponding record.

Massimo

On Aug 12, 11:10 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> ew
>
> jaywalking should never be a replacement for joins...
>
> --
> Thadeus
>

[Thadeus Burgess]

I do not recommend anyone to actually use this. This is just horrible.

> If I only need many2many in one directions I use the list:reference
> and I cache the query that maps the id into the representation of the
> corresponding record.

Then why are you not using the database types that are actually
designed for this? ARRAY comes to mind.

--
Thadeus

On Thu, Aug 12, 2010 at 12:42 PM, mdipierro <mdip...@cs.depaul.edu> wrote:
> True but joins are expensive.
>

>