Redbean-like ORM in web2py

[Chnrxn]

First off, my appreciation to Massimo and the web2py team for working
on such a wonderful product.

I had used RedBeanPHP ORM (http://redbeanphp.com/) in a recent project
on PHP, and I really liked it. It stays true to it's claim - "Combine
The Simplicity of NoSQL With The Power of SQL." - making development a
breeze after some initial learning curve.

I thought the web2py ORM was already one of the best, but I was really
blown away by RedBean, how efficient and productive it is -
* the way it relieves you from specifying the schema during
development
* the way it helps you associate different objects without having to
worry about foreign keys and complicated JOIN
* the way it lets you mix in the power of SQL to fine-tune your query
without proprietary/arcane AND/OR constructs

There has been a POC implementation in Python: http://pypi.python.org/pypi/pybean
which supports SQLite, but looking at it's description, is not meant
for primetime yet.

So my question is, is there a plan to implement these RedBean-like
features in web2py? It can only make development in web2py more
productive and efficient.

[Ross Peoples]

I don't know about future development plans, but I can say that web2py does not use an ORM, it uses a database abstraction layer that generates the proper SQL (and NoSQL) code. Lack of an ORM is sometimes touted as a feature of web2py because ORMs are usually big, complicated, and difficult to learn and maintain. Web2py's DAL is about the simplest, yet most powerful database abstraction layer I've ever used, so I'm very happy with the current solution. However, there is nothing stopping you from using RedBrean or even SQLAlchemy in your web2py projects.

[Vasile Ermicioi]

 However, there is nothing stopping you from using RedBrean or even SQLAlchemy in your web2py projects.

RedBean is a php library... :)

I used it but I can't say that it is better than web2pys DAL 

[pbreit]

Is the main benefit not having to pre-define models? I suppose that could be nice during development but don't find that to be a big problem with DAL.

DAL is pretty integral to Web2py and one of the most popular features. And it has many of the same advantages as RedBean and from my brief look, appears much easier to understand. It's hard to see how something like RedBean would be incorporated. I suppose there's nothing stopping one from trying to create some sort of module or add-on.

[Chnrxn]

It brings in the power of NoSQL. On my part, having used SQLObject,
SQLAlchemy, DAL, and RedBean, I find that Redbean does a wonderful job
of removing obstacles, no doubt many might deem them to be
insignificant, during development. It does make a big difference for
me, especially during development phase when the schema design changes
frequently.

In a sentence, this is the ability to create/adjust schemas on-the-
fly. (#1)

The other major advantage is that RedBean makes associating objects in
different tables a no-brainer without having to deal with foreign keys
explicitly, i.e. an Association Manager (#2)

http://redbeanphp.com/community/wiki/index.php/Associations
http://redbeanphp.com/community/wiki/index.php/Advanced_Associations

You just have to try it to appreciate it.

#1 and #2 would be the top 2 features I would be thrilled to use in
Web2py.

Cheers!

[Massimo Di Pierro]

You can create schemas on the fly with web2py (web2py will do the
alter table). It would be possible to allow redefining a table within
the same http request but why?

you can also do this:

def associate(t1, t2, *fields):
db = t1._db
f1 = t1._tablename+'_id'
f2 = t2._tablename+'_id'
name = t1._tablename+'_'+t2._tablename
t3 = db.define_table(name,Field(f1,t1),Field(f2,t2),*fields)
return (t3[f1]==t1.id)&(t3[f2]==t2.id)
def link(association,rec1,rec2):
table = association.first.first.table
f1,f2 = table.fields[1:3]
return table.insert(**{f1:rec1.id,f2:rec2.id})

db.define_table('person',Field('name'))
db.define_table('dog',Field('name'))

john = db.person.insert(name = 'John')
snoopy = db.dog.insert(name = 'Snoopy')

ownership = associate(db.person,db.dog)
link(ownership, john, snoopy)

rows = db(ownership).select(db.person.name,db.dog.name)

On Jan 30, 3:15 am, Chnrxn <chn...@gmail.com> wrote:
> It brings in the power of NoSQL. On my part, having used SQLObject,
> SQLAlchemy, DAL, and RedBean, I find that Redbean does a wonderful job
> of removing obstacles, no doubt many might deem them to be
> insignificant, during development. It does make a big difference for
> me, especially during development phase when the schema design changes
> frequently.
>
> In a sentence, this is the ability to create/adjust schemas on-the-
> fly. (#1)
>
> The other major advantage is that RedBean makes associating objects in
> different tables a no-brainer without having to deal with foreign keys
> explicitly, i.e. an Association Manager (#2)
>

> http://redbeanphp.com/community/wiki/index.php/Associationshttp://redbeanphp.com/community/wiki/index.php/Advanced_Associations

[Anthony]

On Monday, January 30, 2012 9:37:29 AM UTC-5, Massimo Di Pierro wrote:

You can create schemas on the fly with web2py (web2py will do the
alter table).

I think in RedBean you don't have to define the schema at all. With the DAL, it would look something like:

db.define_table('person')

db.person.insert(name='John')

Notice that the 'name' field was never defined before the insert -- the insert prompts the creation of the 'name' column in the 'person' table (type is inferred based on the data, and altered if necessary based on subsequent inserts). So, it enables use of a schema-based RDBMS more like a schema-less NoSQL db. This "fluid" mode is recommended in development only, after which, you are advised to "freeze" the schema: http://redbeanphp.com/manual/freeze. So, it's taking automatic migrations a step further and doing automatic (inferred) schema definitions as well.

Anthony

[Chnrxn]

Thanks Anthony, that's exactly right. In fact, there is even no need
for us to call db.define_table('person') at all with RedBean. It would
look more like dal.insert(<tablename>, <name>=<value>, ...) and
<tablename> gets created automatically if it does not exist.

The best use case IMO is the ability to store/insert variable
dictionaries like request.vars, say, when you want to have some
general debugging/monitoring for different controllers.

Looking at some of the examples from Massimo, it seems that it might
not be too difficult to implement the association manager with some
extra functions, as well as extending the db.<table>.insert() function
to support on-the-fly schema extensions. (Of course I'm saying this
from a very high level POV; I don't know how much work it would
actually take.)

[Cliff]

> insert prompts the creation of the 'name' column in the 'person' table
> (type is inferred based on the data, and altered if necessary based on
> subsequent inserts)

Wow. I would not be comfortable with this.

[Anthony]

On Wednesday, February 1, 2012 9:02:01 AM UTC-5, Cliff wrote:

> insert prompts the creation of the 'name' column in the 'person' table
> (type is inferred based on the data, and altered if necessary based on
> subsequent inserts)

Wow.  I would not be comfortable with this.

My understanding is that this is only intended for development. Eventually you figure out what the schema should be and "freeze" it, so no such alterations happen in production.

Anthony

[Cliff]

I experience too many unexpected changes during development as it
is. :)
Having an ORM create more would not be good.

During development I might inadvertently attempt to insert a string
into a decimal field. I do dumb stuff like that sometimes, as I think
most of us do. Would the schema then change? How would I know?

[Anthony]

There has been a POC implementation in Python: http://pypi.python.org/pypi/pybean
which supports SQLite, but looking at it's description, is not meant
for primetime yet.

Also, this: https://github.com/stochastic-technologies/goatfish