Experimental in trunk: GAE StringListProperty

[mdipierro]

There are many GAE types that one may want to use. Today I needed
StringListProperty so I extended the web2py GAE apy so that you can
have a field of type

db.define_table('person',Field('names','.StringListProperty()'))

and you can do

db.person.insert(names=['Massimo','Max'])
db(db.person.names=='Massimo').select()

Basically you can put any native type as a web2py type just put it in
a string and start it with a '.'. You can also pass arguments this
way.

It is ugly but works. It is ugly because I'd rather pass an object
than a string. It works because a type has to be a string. It is
experimental because when the new DAL comes this should be replaced by
a better API. This will not stay backward compatible.

Massimo

[mdipierro]

I changed this. It was UGLY.

Now you can do:

from gluon.contrib.gql import gae
db.define_table('person',Field('names',gae.StringListProperty()))

and you can do:

db.person.insert(names=['Massimo','Max'])
db(db.person.names=='Massimo').select()

So you can use any native google type AND you can make your own.

Massimo

[Richard]

great!

The updated API is much better.

[Yarko Tymciurak]

This is directly obvious, but I will state it anyway:

On Dec 30 2009, 1:17 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I changed this. It was UGLY.
>
> Now you can do:
>
>     from gluon.contrib.gql import gae
>     db.define_table('person',Field('names',gae.StringListProperty()))

for a DAL (abstraction layer), this is tied to _one_ persistence store
(the string method was not).

The good part of this (from a programmer's perspective) is that it is
explicit - you know "StingListProperty" is intended to be a gae thing;

The bad part: it erodes the concept of portability, the prime goal of
DAL ...

It may be useful for the moment, but there is a design tension which
is begging for a more comfortable resolution ...

>
> and you can do:
>
>     db.person.insert(names=['Massimo','Max'])
>     db(db.person.names=='Massimo').select()
>
> So you can use any native google type AND you can make your own.

Perhaps you can say a little more on "... and you can make your
own."?

Thanks,
- Yarko

[mdipierro]

I agree. I think there should be a web2py type that merges the
functionalities of ListProperty on GAE and IS_IN_SET(multiple=True)

On Jan 3, 11:52 am, Yarko Tymciurak <resultsinsoftw...@gmail.com>
wrote:

> > > Massimo- Hide quoted text -
>
> - Show quoted text -

[Yarko Tymciurak]

On Jan 3, 12:19 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> I agree. I think there should be a web2py type that merges the
> functionalities of ListProperty on GAE and IS_IN_SET(multiple=True)

This is one instance of what I imagined has to happen when (some time
ago) I mentioned that potentially there would be a separate DAL for
non-RDB stores e.g. MongoDB [C++ - http://www.mongodb.org], couchDB
[Erlang - http://couchdb.apache.org/], Amazon SimpleDB [http://
aws.amazon.com/simpledb/ - compare w/ http://aws.amazon.com/s3] are
listed as document-oreinted on Wikipedia;

GAE - if you follow WIkipedia correlations - is of a class with
Hypertable, Cassandra [Facebook:Java - http://incubator.apache.org/cassandra/],
and Project Voldemort [Linkedin:Java - http://project-voldemort.com/],
and Hadoop [Yahoo search:Java - http://hadoop.apache.org/ ]).

Some things are beginning to become clear about all these cloud
computing vs. storage technology strategies & evolutions - while some
may favor one, they are loosely coupled, so I expect that what serves
the application will take precedence over how that can get implemented
on the cloud (GAE / Big Tables seems to be the cloud image of shared
hosting: you get to run what they provide - java & python in this case
- and use the "db" they have installed - big tables in this case;
Amazon services seem generally closer to a virtualized hosting, with
simpleDB being a nod to a "db" kind of storage app, pre-canned).

I don't think this realization (cloud analogies) should affect much
about DAL evolution: GAE etc. should still be mined for conceptual
similarities, and over time decisions should emerge about what is
worth making portable - e.g. depending on backend, letting backend
facility be accessed, or do / abstract something similar in
framework. DAL will thus help equalize / cross-polinate; this should
be only with the _really_ useful or needed concepts.

</end random thoughts>
- Yarko

[mdipierro]

The new DAL structure (which you can see in gluon/dal.py) has a
standard API (DAL, Table, Field, etc) and delegates everything to an
adapter. There are adapters for all supported RDBS (CPython and
Jython) and there will be some for NODB as well. Adapters have a
hierarchical structure that basically implement what you suggested.

Massimo

On Jan 3, 8:01 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
wrote:

> On Jan 3, 12:19 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > I agree. I think there should be a web2py type that merges the
> > functionalities of ListProperty on GAE and IS_IN_SET(multiple=True)
>
> This is one instance of what I imagined has to happen when (some time
> ago) I mentioned that potentially there would be a separate DAL for
> non-RDB stores e.g. MongoDB [C++ -http://www.mongodb.org], couchDB

> [Erlang -http://couchdb.apache.org/], Amazon SimpleDB [http://
> aws.amazon.com/simpledb/ - compare w/http://aws.amazon.com/s3] are

> listed as document-oreinted on Wikipedia;
>
> GAE - if you follow WIkipedia correlations - is of a class with

> Hypertable, Cassandra [Facebook:Java -http://incubator.apache.org/cassandra/],
> and Project Voldemort [Linkedin:Java -http://project-voldemort.com/],
> and Hadoop [Yahoo search:Java -http://hadoop.apache.org/]).