parse_as_rest queries

[DenesL]

Hi all,

is there any documentation (aside from what is said in the book) about the queries parameter in parse_as_rest?
Some examples would be nice.

Also, looking at the patterns, there does not seem a way to specify a subset in a pattern e.g. (pseudo-code)

"/dogs[pet]/{pet.kind.eq.dog}"

which would retrieve all dogs from the pet table.

Regards,
Denes

[Massimo Di Pierro]

you can say something like:

"/pets[pet]/{pet.kind.eq}"

and call /pets/dog or /pets/cat

It is not documented because I am convinced this syntax is definitive. It needs more etsting and as you suggest it may be richer.

massimo

[DenesL]

Yes, from the docs it is clear that one could use such syntax but the idea is to hide it somehow.
So instead of /pets/dog I want just /dogs
Note that I am providing all parameters for the query in the pseudo-code {pet.kind.eq.dog} to avoid having another arg.

[Massimo Di Pierro]

It could be possible via routes but it would be nice it the syntax were to allow it. I stopped developing it because I though instead of reinventing the wheel with this syntax we may want to support some standard. Is there any?

[DenesL]

+1 for an extended syntax instead of routes.

Blog post about http://blog.2partsmagic.com/restful-uri-design/ which discusses some schemes (about halfway down, with the title "Choosing a URI schemes for resource hierarchies" (sic)).

One thing to think about is how to define the creation of new resources via templates,
e.g. /person/new
where "new" would be a reserved word; the template would be POSTed when filled.

About the /dogs issue:
it may be solved by having the query parameter at the pattern level instead of at the parse_as_rest level:
patterns = [ ('/dogs[pet]', query=db.pet.kind=='dog') ]
pros/cons?


Denes

[DenesL]

^bump^

[Massimo Di Pierro]

I think this can be implemented. Will try later today.

[Massimo Di Pierro]

I have implemented what you requested:

patterns = [ ('/dogs[pet]', db.pet.kind=='dog') ]

Can you please check it?

On Monday, 31 December 2012 11:30:34 UTC-6, DenesL wrote:

[DenesL]

Thank you, it still needs more work:

Traceback (most recent call last):
  File "C:\w2p\trunk\gluon\restricted.py", line 212, in restricted
    exec ccode in environment
  File "C:\w2p\trunk\applications\test\controllers/rest.py", line 28, in <module>
  File "C:\w2p\trunk\gluon\globals.py", line 193, in <lambda>
    self._caller = lambda f: f()
  File "C:\w2p\trunk\gluon\globals.py", line 157, in f
    return rest_action(*_self.args, **_self.vars)
  File "C:\w2p\trunk\applications\test\controllers/rest.py", line 12, in GET
    parser = b1.parse_as_rest(patterns,args,vars)
  File "C:\w2p\trunk\gluon\dal.py", line 7221, in parse_as_rest
    tokens = pattern.split('/')
AttributeError: 'tuple' object has no attribute 'split'

I tried fixing it by adding the basequery handling code there too but then it fails with:

Traceback (most recent call last):
  File "C:\w2p\trunk\gluon\restricted.py", line 212, in restricted
    exec ccode in environment
  File "C:\w2p\trunk\applications\test\controllers/rest.py", line 28, in <module>
  File "C:\w2p\trunk\gluon\globals.py", line 193, in <lambda>
    self._caller = lambda f: f()
  File "C:\w2p\trunk\gluon\globals.py", line 163, in f
    raise e
TypeError: Incorrect padding

Denes

[Massimo Di Pierro]

I have fixed the first error too but not sure where the second comes from. Can you help?

[DenesL]

It seems to be from the data, it is a legacy table.
Using 4607 trunk a manual select gives:

Traceback (most recent call last):

  File "<console>", line 1, in <module>
  File "C:\w2p\trunk\gluon\dal.py", line 9181, in select
    return adapter.select(self.query,fields,attributes)
  File "C:\w2p\trunk\gluon\dal.py", line 1637, in select
    return self._select_aux(sql,fields,attributes)
  File "C:\w2p\trunk\gluon\dal.py", line 1618, in _select_aux
    return processor(rows,fields,self._colnames,cacheable=cacheable)
  File "C:\w2p\trunk\gluon\dal.py", line 1989, in parse
    value = self.parse_value(value,ft,blob_decode)
  File "C:\w2p\trunk\gluon\dal.py", line 1839, in parse_value
    return self.parsemap[key](value,field_type)
  File "C:\w2p\trunk\gluon\dal.py", line 1892, in parse_blob
    return base64.b64decode(str(value))
  File "C:\Python26\lib\base64.py", line 76, in b64decode
    raise TypeError(msg)
TypeError: Incorrect padding

[DenesL]

Suggestions to override parse_blob are welcome.

[Massimo Di Pierro]

web2py uses b64encode/decode to store/retrieve data in blobs. Legacy tables probably do not do it.

You need you make your own custom adapter to override a method. For example for PostgreSQL:

from gluon.dal import ADAPTERS, UseDatabaseStoredFile,PostgreSQLAdapter

class MyPostgresAdapter(PostgreSQLAdapter):

     drivers = ('psycopg2',)

     def parse_blob(self, value, field_type): return value

ADAPTERS['mypostgres'] = MyPostgresAdapter

db = DAL('mypostgres://.....')

[DenesL]

Thank you.

[DenesL]

This also seems to work:

db._adapter.parse_blob=lambda value,field_type: value

Any cons?.

[Massimo Di Pierro]

This may affect other concurrent apps which use this adapter. Not sure.