I've been keeping half an eye on web2py for a while, since it seems to fill a previously untapped niche in the web framework world (TTW development without a lot of complexity).
I decided to check up tonight and I have to say I'm amazed. I'm mildly leery of the fact that it uses a custom ORM rather than SQLAlchemy (SA seems sufficient and is rapidly becoming the de facto Python ORM), but overall, web2py seems to offer a rather appealing way to manage web applications.
I was especially impressed by the number and quality of appliances built on top of it (and the fact that many of them are from third parties is encouraging).
I was also pleased to see that it supports alternative template engines (so I could use Breve with it if I wanted to [and I do]).
SQL doesn't naturally lend itself to nested data. However, there are several clever solutions to managing tree-like data in SQL, but most of them involve one of the following:
- adding columns to your tables that explicitly map the current nesting (and triggers to keep them sync'd)
- a huge brain (google for "sql nested sets")
If you use PostgreSQL, you can avoid both of these drawbacks (well, a huge brain isn't necessarily a drawback if you have one available - unfortunately for me, most of the huge brains I know belong to evil robots). Actually, any database with a decent procedural language will work, but I only know of one in the open source world: PostgreSQL.
Let's assume we have a table that was created like this:
CREATE TABLE accounts ( id SERIAL PRIMARY KEY NOT NULL, accounts_id FOREIGN KEY (accounts), account_name TEXT );
And it's got records like this:
account_name | id | accounts_id
---------------------+-----+-------------
account | 78 |
sub account | 102 | 78
sub sub account | 151 | 102
As you can see, this table represents a tree graph, where an account can have one or more subaccounts.
This is a really simple and easy-to-maintain system. Unfortunately, it's not so easy to ask questions like "given an account, what are all the subaccounts of that account?" Obviously if there's only one level of subaccounts, the answer is easy, but if you have multiple levels, then it isn't quite so simple.
Here's a fairly simple PL/PGSQL function that can answer that particular question for you. Given the id of an account, it returns a list of rows informing you of all the children of that account.
CREATE FUNCTION get_subaccounts ( parent_id INTEGER )
RETURNS SETOF accounts AS $$
DECLARE
child accounts;
schild accounts;
BEGIN
FOR child IN SELECT * FROM accounts WHERE accounts_id=parent_id LOOP
RETURN NEXT child;
FOR schild IN SELECT * FROM get_subaccounts ( child.id ) LOOP
RETURN NEXT schild;
END LOOP;
END LOOP;
RETURN;
END;
$$ LANGUAGE 'plpgsql';
You can now do a query like this:
db=# select id, accounts_id from get_subaccounts ( 78 ); id | accounts_id -----+------------- 102 | 78 151 | 102 (2 rows)
After reading this article about how the OLPC initiative is going to embrace Windows on the XO, I was struck about how sometimes being focused on a single solution can be detrimental to your goals.
Negroponte said he was mainly concerned with putting as many laptops as possible in children's hands.
On the surface, this is laudable. However this is a silly goal unless there's a corollary. In the OLPC project, education is the corollary. Without the education aspect, we may as well expect the XO's to be used mainly for browsing MySpace and internet porn. So simply "getting laptops... in children's hands" isn't sufficient. They don't need laptops so much as they need learning tools. If the laptop isn't a learning tool then it's just more strain on the environment and a distraction from real solutions.
This is where Negroponte's narrow vision begins to fail his goal.
Proprietary software, such as Windows, OSX, or Flash, isn't viable as a learning environment unless you are able to spend money to make it into one. The entire point of OLPC is to get learning tools into the hands of children who have no money. Providing them with proprietary software is providing them with a dead-end solution. Will Microsoft continue to provide them with free upgrades that are available over low-bandwidth connections? What about development tools and API's? Can we expect that in ten years the XO will be as up-to-date as Windows 98 is today? Microsoft doesn't have a good track record of supporting legacy software and interfaces nor for providing an inexpensive upgrade path.
I consider providing Windows-based XO's the equivalent of selling African farmers crop seeds that contain the so-called "death gene". It solves their immediate problem today, but gives them no way to become self-sufficient. In fact, all it guarantees is that they will become locked into the corporate food-chain and another revenue source for Microsoft (or more likely, another abandoned project, once the PR has faded).