[w2py-dev] Turning DAL more like an ORM

[Álvaro Justen [Turicas]]

Hi folks,
I think code legibility counts (a lot) and sometimes to read some
web2py DAL code is not the best thing.
Thinking in this I've created some simple methods to the Table class
and a little app-example that I describe here:

File test/models/db.py:
<code>
db = DAL('sqlite://test.db')

db.define_table('person',
Field('name'),
Field('age', 'integer'),
)

Person = db.person

if Person.total() == 0:
Person.insert(name='Álvaro', age=23)
Person.insert(name='Elidiane', age=21)
Person.insert(name='Massimo', age=40)
Person.insert(name='Someone', age=99)
</code>

1- The first thing is using just Person instead of db.person. In the
most cases we have just one database and writing 'db.' all times
really sucks.

File test/controllers/person.py:
<code>
def list():
return dict(persons=Person.all(), total=Person.total(),
first_person=Person.first(), last_person=Person.last())
</code>

File test/views/person/list.html:
<code>
...
<ul>
{{for person in persons:}}
<li> {{=person.name}} ({{=person.age}} years old) </li>
{{pass}}
</ul>
...
</code>

I've created the methods all, total, first and last that are
self-explanatory. The code above is very great when thinking in
legibility.

The files attached are:
- patch_gluon.Table.diff: the implementation of these methods to
Table class - we can optimize it (if needed) using other Table's
methods instead .select() .count() etc.
- web2py.app.test.w2p: the test app that include the codes I've cite above.

I think it's just the beginning. Things like:
db((db.table.field > X) && (db.field.other_field <
Y)).select(orderby=~db.table.field, limitby=(0, 10))
could be less painful to write (and, most important: to read and understand).

What do you think?

--
Álvaro Justen - Turicas
http://blog.justen.eng.br/
21 9898-0141

--
mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/

[Álvaro Justen [Turicas]]

I was thinking in my solution and thought that it could be more general.
We could use __getattr__ on Table class to create attributes like:

- Person.all
- Person.all_by_name
- Person.all_by_name_desc
- Person.all_by_age
- Person.all_by_age_desc

- Person.first
- Person.first_by_name
- Person.first_by_name_desc
- Person.first_by_age
- Person.first_by_age_desc

- Person.last
- Person.last_by_name
- Person.last_by_name_desc
- Person.last_by_age
- Person.last_by_age_desc

And also:
- Person.find_by_name('chars to find')
- Person.find_by_age(Person.age > 50)

It looks like what Rails do. I feel this very legible and rapid to write.
Also we can implement this quickly.

[Álvaro Justen [Turicas]]

On Mon, May 3, 2010 at 10:17, Álvaro Justen [Turicas]

We could also create gluon/orm.py and define some classes (as Table)
that just inherit from sql.py/dal.py. So we'll have DAL and separated
ORM and user can use DAL() or ORM() to your database.

I can start the development of this orm.py. What do you think about this?

[Thadeus Burgess]

Please do not turn the awesomeness that is the web2py DAL into django.
I beg of you.

orm.py might be doable. Even if you declare ``db = ORM()`` you still need to

Person = db.define_table('person')

I don't get it.

db(Person.age > 50).select()

Is much more readable to me, (and logical), than

Person.find_by_age(Person.age > 50),

Here you repeat age twice, and the word person. I think if I am doing
Person.find_by_age_gte(50) is better.

I won't use it. I really dislike this syntax. The DAL is the main
reason I choose to go with web2py instead of django or pylons.

--
Thadeus





On Mon, May 3, 2010 at 9:10 AM, Álvaro Justen [Turicas]

[Massimo Di Pierro]

I agree with Thedeus.
Anyway, there is an ORM for web2py and it has the very same syntax as
Django's:

http://www.web2py.com/AlterEgo/default/show/189

Massimo

[Álvaro Justen]

On Mon, May 3, 2010 at 11:33, Thadeus Burgess <thad...@thadeusb.com> wrote:
> Please do not turn the awesomeness that is the web2py DAL into django.
> I beg of you.
>
> orm.py might be doable. Even if you declare ``db = ORM()`` you still need to
>
> Person = db.define_table('person')
>
> I don't get it.
>
> db(Person.age > 50).select()
>
> Is much more readable to me, (and logical), than
>
> Person.find_by_age(Person.age > 50),
>
> Here you repeat age twice, and the word person. I think if I am doing
> Person.find_by_age_gte(50) is better.

I'm just thinking on this and we could have an experimental version
(that won't be backward compatible until it turns stable) to test and
try new syntaxes.
I'm thinking in something like this for the last query above:

old_persons = Person.age > 50

> I won't use it. I really dislike this syntax. The DAL is the main
> reason I choose to go with web2py instead of django or pylons.

I'm not talking about creating an ORM like Django's.
I want to write more readable code in web2py applications that I
write, but writing less code.
What I'm saying is that we can create a new way to do this. We don't
need to copy Django.

[Thadeus Burgess]

We can already do this.

qry_old_persons = db.person.age > 50

And if I assigned Person....

Person = db.define_table('person')

qry_old_persons = Person.age > 50
old_people = db(qry_old_persons).select()
all = db().select(Person.ALL)
first = db().select(Person.ALL).first()
last = db().select(Person.ALL).last()

Ok so maybe it would be nice if Person.qALL() would return a query
(db.person.id > 0)

db(Person.qALL()).select()

[Massimo Di Pierro]

On May 3, 2010, at 10:09 AM, Thadeus Burgess wrote:

> We can already do this.
>
> qry_old_persons = db.person.age > 50
>
> And if I assigned Person....
>
> Person = db.define_table('person')
> qry_old_persons = Person.age > 50
> old_people = db(qry_old_persons).select()
> all = db().select(Person.ALL)
> first = db().select(Person.ALL).first()
> last = db().select(Person.ALL).last()
>
> Ok so maybe it would be nice if Person.qALL() would return a query
> (db.person.id > 0)

The fact that adding methods to a table prevent a field with the same
name.
The one method I have never implemented is

Table.__call__ and Field.__call__

waiting for some cleaver application for them

[Massimo Di Pierro]

Alvaro,

Because this is just syntactic sugar, does not add functionality, and
you will never get everybody to agree on the syntax.
I think if you have time to work on this, I have a better project for
you.

http://groups.google.com/group/web2py/browse_thread/thread/ecf1856e52570ff5#

This would be a killer functionality.

Massimo

[Massimo Di Pierro]

Here is what I would like to see, in order of importance:

1) ability to read existing databases without creating models.
Requires some API that queries the DB for existing tables, make a
guess about mapping SQL field types into web2py types, returns some
dict-like representation of the DB.

2) app-level routes. Requires a way for routes.py to delegate some
paths to applications/someapp/routes.py

3) Port gql.py to dal.py (I promised I would do it but I have been
lagging). This is on my personal todo list.

4) more tests. tests and more tests.

5) better error messages for common failures

6) A replacement for T2/T3/T4, etc. I finally have a good design in
mind but need to implement it. I will discuss it later in a separate
thread.

Massimo

[Yarko Tymciurak]

I would add this on the list (somewhere):

n)  for layout, add ability for 2 things to template:  

       [1] named extension points (including current "default");  -- I don't think this will be too hard;

       [2] ability to override sections of default layout (i.e.   named blocks) -- I think this will require more change to templates code (i.e. parsinng)

--
Regards,
- Yarko

[Thadeus Burgess]

I would like to add

[9] NODB support for the DAL (ie: mongo, couch)
[10] A new form system, (this includes widgets, validators, converters)
[11] Comments in gluon core.
[12] PEP-8 Gluon
[13] DAL signal/slot (I have worked some with this, but not quite
happy with it atm)
[14] New DAL.
[15] Named blocks, and filters into template system.
[16] Routes converters, ie: often times args(0) is the id for a
record, it would be nice to specify this in the URL and have it
auto-convert to my type instead of having to go ``try:
int(request.args(0)) except: raise(404)``

Uliweb has already a patched version of web2py templates.py that
support named blocks. This might be something to look into integrating
? Massimo, could you please explain the inconsistencies you have
experienced with blocks ?

--
Thadeus

[Massimo Di Pierro]

On May 3, 2010, at 12:09 PM, Thadeus Burgess wrote:

> I would like to add
>
> [9] NODB support for the DAL (ie: mongo, couch)

+1

> [10] A new form system, (this includes widgets, validators,
> converters)

This should be an add-on, not a replacement. I do not think there
should be a single form system. It may become a replacement over time.

> [11] Comments in gluon core.

+1 but help me write them. Jonathan has been great at this.
> [12] PEP-8 Gluon
Once in a while we tried. Full compliance is impossible but I will
always take patches in this direction.

> [13] DAL signal/slot (I have worked some with this, but not quite
> happy with it atm)

This has come up. why should the signal slot be restricted to DAL?
Let's discuss it more before you implement it.
> [14] New DAL.
+1

> [16] Routes converters, ie: often times args(0) is the id for a
> record, it would be nice to specify this in the URL and have it
> auto-convert to my type instead of having to go ``try:
> int(request.args(0)) except: raise(404)``

I usually just define a function get(table,x=0) which gets
table[request.args(x)] in a try except and redirects to 'error' on
failure.

> [15] Named blocks, and filters into template system.

> Uliweb has already a patched version of web2py templates.py that
> support named blocks. This might be something to look into integrating
> ? Massimo, could you please explain the inconsistencies you have
> experienced with blocks ?

Tell me more about filters. I really cannot stand Django's filters
they are non-pythonic.
I do not have a strong objection into incorporating blocks. They do
present logical inconsistencies.

Parent {{block a}}xxx{{end block}}yyy{{block b}}zzz{{end block}}
Child extends parent {{block a}}rrr{{end block}}sss{{block b}}ttt{{end
block}}

I expect the output to be rrryyyzzz. Where did sss go?

I think the current {{def blockname():}}...{{return}} is more
pythonic. The issue is in the order of execution.

[Thadeus Burgess]

I don't like django filters either. I like jinja2 filters.

As I think more on the matter, we can already do this.

So say I want the following filter..

{{=myobj.submitted_on|prettydate}}

I could just in a model.

def prettydate(date): return strftime(etcetc)

{{=prettydate(myobj.submitted_on)}}

Which stays pythonic, its just a matter of teaching people that we can do this.

--
Thadeus

[Thadeus Burgess]

With blocks, you lose sss completely, because your not supposed to put
anything random in there.

Assume the following template.

<html>
<title>
{{ block title }}
{{=request.function}}
{{ end }}
</title>
<body>
<header>
<nav>
<content>{{include}}
<footer>{{ block footer}} copyright {{ end }}
</body>
</html>

So in your index.html you have the following code

{{ block title }}
Hello, I am an Index Page
{{ end }}

Here is a list of people
{{ = SQLTABLE(db.persons) }}

{{ block footer }}
copyright 2010 superman inc.
{{ end }}

So anything that is not within a block, gets stuck where {{ include }}
is on the parent template. You don't lose `sss`, I do not see a
problem, am I missing something?

The {{ def blockname(): pass }} does not work. You run into
"execution" issues, in that you might define the function in child,
but it is overwritten in parent.

[Massimo Di Pierro]

OK. I am sold. If uliweb has this already we should merge it with
web2py. Any volunteer?

[Thadeus Burgess]

I can work on it tonight and tomorrow. I have been looking into this
already this past weekend.

--
Thadeus





On Mon, May 3, 2010 at 1:24 PM, Massimo Di Pierro
<mdip...@cs.depaul.edu> wrote:
> volunteer

[Yarko Tymciurak]

First:   I would forget about 'others' filters for a moment, and talk about _what_ is wanted to implement.

I want multiple insertion points (mostly to get rid of the trickiness of using   response.files.append(URL(....))  --- this depends on web2py_ajax.html, which is a single insertion point in layout...   named extend sections would lead to relaxing this brittleness:

parent   {{include}}   is currently how "extends" includes a child template contents.

I would like to change this to (lets say):  Parent {{extend includes}}

Child:  {{extends layout.html::includes}}  stuff to go into the includes area  {{ extends layout.html::second_entry_point}}  stuff that goes there.

Contrast that with blocks: which I would treat like override-able class pieces, i.e.  if parent has {{block body_layout}} which does 3 panels across the center, I would want a child to replace that with (say) one panel.

BTW - I would (in this way of thinking) expect your output (above) to be:   rrryyyttt (with "sss" into the default extension insertion area, if parent has one.  

- Yarko 

--

mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details    : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official    : http://www.web2py.com/

--
Regards,
- Yarko

[Massimo Di Pierro]

Thanks. Great Thadeus.
In case you need to talk with limodou, he was a web2py user and he is
a very friendly. perhaps we may want to converge one one version. As
you know our constraint is backward compatibility.

Massimo

[Álvaro Justen]

On Mon, May 3, 2010 at 12:18, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:
> Alvaro,
>
> Because this is just syntactic sugar, does not add functionality, and you
> will never get everybody to agree on the syntax.

Syntatic sugar matters. :-)

> I think if you have time to work on this, I have a better project for you.
>
> http://groups.google.com/group/web2py/browse_thread/thread/ecf1856e52570ff5#
>
> This would be a killer functionality.

Yes, I worked in this in the past and have in some place in my HD an
partial-functional version to SQLite.

[Massimo Di Pierro]

On May 3, 2010, at 1:47 PM, Álvaro Justen wrote:

> Yes, I worked in this in the past and have in some place in my HD an
> partial-functional version to SQLite.

I think this would me most useful for postgresql, mysql and mssql
since that is >90% of our users.

[Álvaro Justen]

On Mon, May 3, 2010 at 12:24, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:
> Here is what I would like to see, in order of importance:
>
> 1) ability to read existing databases without creating models.  Requires
> some API that queries the DB for existing tables, make a guess about mapping
> SQL field types into web2py types, returns some dict-like representation of
> the DB.

As I said in other email I did some tests on this field in the past
with SQLite. I'll search the code and send it.

> 2) app-level routes. Requires a way for routes.py to delegate some paths to
> applications/someapp/routes.py
>
> 3) Port gql.py to dal.py (I promised I would do it but I have been lagging).
> This is on my personal todo list.
>
> 4) more tests. tests and more tests.
>
> 5) better error messages for common failures
>
> 6) A replacement for T2/T3/T4, etc. I finally have a good design in mind but
> need to implement it. I will discuss it later in a separate thread.

I think we need a wish list in the wiki and then create a roadmap
based on priorities.
Ah, a roadmap...I'm saying this for a long time: web2py needs a
consistent roadmap. We need to put priorities on the next features
that will be implemented.

> Massimo
>
> --
> mail from:GoogleGroups "web2py-developers" mailing list
> make speech: web2py-d...@googlegroups.com
> unsubscribe: web2py-develop...@googlegroups.com
> details    : http://groups.google.com/group/web2py-developers
> the project: http://code.google.com/p/web2py/
> official    : http://www.web2py.com/

--
Álvaro Justen - Turicas
http://blog.justen.eng.br/
21 9898-0141

[Álvaro Justen]

On Mon, May 3, 2010 at 15:51, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:
>
> On May 3, 2010, at 1:47 PM, Álvaro Justen wrote:
>
>> Yes, I worked in this in the past and have in some place in my HD an
>> partial-functional version to SQLite.
>
> I think this would me most useful for postgresql, mysql and mssql since that
> is >90% of our users.

Yes, but having SQLite code is just a start.

I was thinking about "there should be only one way to do something"
and having DAL and ORM will be counter this philosophy.
But I really want more readable queries to database in web2py.

> --
> mail from:GoogleGroups "web2py-developers" mailing list
> make speech: web2py-d...@googlegroups.com
> unsubscribe: web2py-develop...@googlegroups.com
> details    : http://groups.google.com/group/web2py-developers
> the project: http://code.google.com/p/web2py/
> official    : http://www.web2py.com/

--
Álvaro Justen - Turicas
http://blog.justen.eng.br/
21 9898-0141

[Álvaro Justen]

On Mon, May 3, 2010 at 15:51, Álvaro Justen <alv...@justen.eng.br> wrote:
> On Mon, May 3, 2010 at 12:24, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:
>> Here is what I would like to see, in order of importance:
>>
>> 1) ability to read existing databases without creating models.  Requires
>> some API that queries the DB for existing tables, make a guess about mapping
>> SQL field types into web2py types, returns some dict-like representation of
>> the DB.
>
> As I said in other email I did some tests on this field in the past
> with SQLite. I'll search the code and send it.
>
>> 2) app-level routes. Requires a way for routes.py to delegate some paths to
>> applications/someapp/routes.py
>>
>> 3) Port gql.py to dal.py (I promised I would do it but I have been lagging).
>> This is on my personal todo list.
>>
>> 4) more tests. tests and more tests.
>>
>> 5) better error messages for common failures
>>
>> 6) A replacement for T2/T3/T4, etc. I finally have a good design in mind but
>> need to implement it. I will discuss it later in a separate thread.
>
> I think we need a wish list in the wiki and then create a roadmap
> based on priorities.
> Ah, a roadmap...I'm saying this for a long time: web2py needs a
> consistent roadmap. We need to put priorities on the next features
> that will be implemented.

Please add the features with your name at:
http://wiki.web2py.com/Wishlist
I've added Massimo's, Yarko's and Thadeu's wishes.

Let's discuss this at the list. I think we need to call users (not
only developers) to create this wishlist.
So, we decide what are the priorities based on web2py philosophy and
create the roadmap.

[Thadeus Burgess]

We have web2py.uservoice.com


--
Thadeus

[Thadeus Burgess]

It all looks the same to me =/

--
Thadeus

[Thadeus Burgess]

[16] named default URL. To keep backwards compatibility it will stay
defaulted to 'init/default/index'

However it will be nice to be able to go

default.application = 'good'
default.controller = 'morning'
default.function = 'world'

So if I navigate to '/' it will interpolate as '/good/morning/world'
instead of '/init/default/index'.

This way we can also specify default "apps" that can be named other than init.

The biggest issue I am having is where should this be integrated at.
Could wsgihandler.py overwrite a flag variable in main.py ?

[Yarko Tymciurak]

On Mon, May 3, 2010 at 1:52 PM, Álvaro Justen <alv...@justen.eng.br> wrote:

On Mon, May 3, 2010 at 15:51, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:
>
> On May 3, 2010, at 1:47 PM, Álvaro Justen wrote:
>
>> Yes, I worked in this in the past and have in some place in my HD an
>> partial-functional version to SQLite.
>
> I think this would me most useful for postgresql, mysql and mssql since that
> is >90% of our users.

I remember this about a year ago - wehweh (or someone) really wanted this - I found the file with the core code in sqalchemy - they seemed to do a really good job of it, and I suggested people start there;  as I remember it was well organized, and well structured.

If you want, I will search to the email I sent - it pointed out the file / lines where everything was "revealed", and (if I remember) was not overly hinging on a particular db.

Regardless if you start from that, adapt that, or go your own way - you should look at how they did it first.  It is a very good example, I thought.

- Yarko

Yes, but having SQLite code is just a start.

I was thinking about "there should be only one way to do something"
and having DAL and ORM will be counter this philosophy.
But I really want more readable queries to database in web2py.

> --

> mail from:GoogleGroups "web2py-developers" mailing list
> make speech: web2py-d...@googlegroups.com
> unsubscribe: web2py-develop...@googlegroups.com
> details    : http://groups.google.com/group/web2py-developers
> the project: http://code.google.com/p/web2py/
> official    : http://www.web2py.com/

--

Álvaro Justen - Turicas
 http://blog.justen.eng.br/
 21 9898-0141

--

mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details    : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official    : http://www.web2py.com/

--
Regards,
- Yarko

[Massimo Di Pierro]

I am not convinced we really need this becuase you can already use
routes for this purpose.

[Massimo Di Pierro]

yes please.

[Thadeus Burgess]

Good point, and if I had app level routes :)



--
Thadeus





On Mon, May 3, 2010 at 9:14 PM, Massimo Di Pierro

[Thadeus Burgess]

Uliweb templates contain an extra syntax to help with writing output,
I am wondering if we should include this.

As of now, if you want to render a variable that is not escaped, you
have to write

{{=XML(my_post, escape=False)}}

Uliweb contains '<<' and will do this. So using the above example.

{{<<my_post}}

Accomplishes the exact same thing.

what do you think?

[Massimo Di Pierro]

I think it is redundant and therefore from an education point of view
I would prefer not. The << will also confuse syntax highlighting and
html editors.
My objection is not very strong anyway but if people really want this
I'd rather use {{== instead of {{<<.

Massimo

[Thadeus Burgess]

I could go for ``{{==`` as a shortcut syntax. Its just syntatic sugar anyways :)

Lets here more opinions on the matter.

--
Thadeus





On Mon, May 3, 2010 at 9:27 PM, Massimo Di Pierro

[Richard]

not sure if the web2py wiki is ready for this:
http://groups.google.com/group/web2py/browse_thread/thread/82df3192a6af7418

The user voice page already has a few of these ideas:
http://web2py.uservoice.com/forums/42577-general
and people can vote to show priority.

Richard

On May 4, 5:02 am, Álvaro Justen <alv...@justen.eng.br> wrote:
> On Mon, May 3, 2010 at 15:51, Álvaro Justen <alv...@justen.eng.br> wrote:

[Massimo Di Pierro]

Thanks Richard

[Thadeus Burgess]

Can we start testing the new template.py now!?

I have tested on my personal apps and it works. Beautiful to see block
support in web2py.

Everything is the same except now we have blocks

{{ block title}}
Live long and prosper.
{{ end }}

If you define a block in a child, it will overwrite the same named
block in the parent, however if you don't, it will use the default
inside the block. We still have the same {{include}} syntax. So
basically, anything that is not in a block defined in the parent
template, gets stuck here.

--
Thadeus

[Álvaro Justen]

On Tue, May 4, 2010 at 03:02, Thadeus Burgess <thad...@thadeusb.com> wrote:
> Can we start testing the new template.py now!?
>
> I have tested on my personal apps and it works. Beautiful to see block
> support in web2py.
>
> Everything is the same except now we have blocks
>
> {{ block title}}
>  Live long and prosper.
> {{ end }}
>
> If you define a block in a child, it will overwrite the same named
> block in the parent, however if you don't, it will use the default
> inside the block. We still have the same {{include}} syntax. So
> basically, anything that is not in a block defined in the parent
> template, gets stuck here.

So if we have a block we don't need a include, right?
I think we could use this thread just to put ourt wishes and brainstorming.
Could you create a new thread to talk about just blocks on templates?

[Massimo Di Pierro]

Did you take the regular expressions from the web2py version or form
the uliweb version?

Massimo

> <template.py>

[Thadeus Burgess]

On http://wiki.web2py.com/Wishlist what should we do with completed items?

Any other ideas, what should we work on next!?

--
Thadeus





On Tue, May 4, 2010 at 5:56 AM, Massimo Di Pierro

[Massimo Di Pierro]

"NODB support for the DAL (ie: mongo, couch)" scores first in user
voice and your list.

The new DAL has been there for a while. It needs lots of small
improvements but the many missing piece is a GAE adapter. Once we have
a GAE adapter should be easy to write a MongoDB adapter and CouchDB
adapter.

[Thadeus Burgess]

timeline on this? I wish I knew enough about the DAL to help with it,
but that is a work of ingenuity :)

Maybe you should write a white-paper on how the DAL works to bring me
up to speed!

--
Thadeus





On Wed, May 5, 2010 at 1:05 PM, Massimo Di Pierro

[Massimo Di Pierro]

You have good point. I will write it by the end of the week. It will
help myself too clarify what is done and what is not done.

Massimo

[Massimo Di Pierro]

Just to kick this off...

Each database engine has an adapter class. db=DAL(...) is an object
that contains db._adapater, an instance of the chosen adapter.
The adapter contains functions that belong to different categories.

- Lower case functions. These are functions that generally correpond
to exposed API of db like select, insert, update, delete. the public
API delegate the corresponding task to the corresponding adapter method.
- Upper case functions. These generate SQL or parts of SQL. A GAE
adapter most likely would not have them.

One of the main differences dal.py and sql.py is that sql.py was
generating SQL directly (for example partial WHERE clauses). This did
not work on GAE that why it has its own module. dal.py instead always
stores an abstract representation (a tree) of the WHERE clause and the
adapter serializes it in SQL (or API calls for GAE).

Hope this makes some sense.

Massimo



On May 5, 2010, at 1:09 PM, Thadeus Burgess wrote:

[Yarko Tymciurak]

On Wed, May 5, 2010 at 1:19 PM, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:

Just to kick this off...

Each database engine has an adapter class. db=DAL(...) is an object that contains db._adapater, an instance of the chosen adapter.
The adapter contains functions that belong to different categories.

- Lower case functions. These are functions that generally correpond to exposed API of db like select, insert, update, delete. the public API delegate the corresponding task to the corresponding adapter method.
- Upper case functions. These generate SQL or parts of SQL. A GAE adapter most likely would not have them.

.... nor would  MongDB API, or CouchDB API, I think... 

--
Regards,
- Yarko

[Massimo Di Pierro]

True. In fact once the GAE adptater is done the others would be trivial.

[Massimo Di Pierro]

Did we ever agree on a launch time. Let me know because if we did I forgot.

On May 5, 2010, at 8:40 PM, Yarko Tymciurak wrote:

[Yarko Tymciurak]

On Wed, May 5, 2010 at 8:51 PM, Massimo Di Pierro <mdip...@cs.depaul.edu> wrote:

Did we ever agree on a launch time. Let me know because if we did I forgot.

... did you mean launch - of DAL (and GAE, Couch, etc.   NODAL)?  i.e. a schedule?   flag in the sand?

.... not sure I saw anything...

- Yarko 

[Massimo Di Pierro]

Sorry private communication with a typo (I am very confused because typing in the dark waiting for son to fall asleep).

It was supposed to be "lunch" as in "food".