On Sat, Feb 27, 2010 at 12:29 AM, jlist9 <[email protected]> wrote:
> Yeah, that's why I think using existing tools such as SQLAlchemy shouldn't
> be a bad idea, although I know you are not a fan of ORMs :-)

No, I'm not a fan. But, I'm not strictly against using SQLAlchemy
internally in this project. I'm against assuming that users would use
it in their apps.

BTW, this is the query that gives you insight into the relationships
between tables you mentioned eariler:

select * from information_schema.referential_constraints where
unique_constraint_schema='public';

There are many queries in information_schema schema that you can shoot
to get a whole lot of data about practically any aspect of your
database. I imagine every notable DBMS must have a way to do the same,
since there are programs like PHPMyAdmin, SQLite browser, etc, that
are all capable of introspecting.

I still vote for writing this project using web.db rather than
SQLAlchemy. Most people around here hopefully know web.db fairly well,
and the code base is small enough so developers don't have to worry
about upstream bugs (that much). The resulting app would probably be
lighter as well. At least that's how I see it.

-- 
Branko Vukelić

http://foxbunny.tumblr.com/
http://www.flickr.com/photos/16889...@n04/
http://www.twitter.com/foxbunny
http://github.com/foxbunny

-- 
You received this message because you are subscribed to the Google Groups 
"web.py" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/webpy?hl=en.

Reply via email to