Thread: [SQLObject] SQLObject Cookbook: persons & roles, recipes 01 and 02
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Carlos R. <car...@gm...> - 2005-03-16 00:43:36
Attachments:
recipe-01-person-role.py
recipe-02-person-role.py
|
Hi all, That's my first contribution to a 'SQLObject Cookbook'. It's not supposed to substitute the documentation; it's supposed to be an addition to it, a kind of reference of how to do stuff with SQLObjects. It's better than a FAQ, IMHO, because it's possible to structure it as a reference for programmers; we can discuss use cases, shortcomings, and particular programming tips. My proposal is to post and discuss the recipe on the list (where many eyes can see it), debate it, and then add it to the Wiki. Attached to this message are two Python files, named 'recipe-01-person-role.py' and 'recipe-02-person-role.py'. It's a simple Person/Role schema, without using inheritance. Some things worth noting are: -- the schema itself is very simple. That's the very goal of it. -- it's fairly well documented IMHO (but feel free to tell me otherwise <wink>). -- the test code is supposed to be read by the user and run, so he can inspect how things are supposed to work, including errors and corner cases. -- please note that I used a MySQL connection for my tests, using user name = 'sqlobject', passwd = 'sqlobject', and database 'cookbook'. That's one of the things that bugged me - I think that the Cookbook should use a standard database backend as much as possible. The alternatives (IMHO) are MySQL and Sqlite. What do you think? Said that, I welcome comments, revisions, or even the entire rejection of the code as posted. There are many things that can be improved, but that's the goal here. Thanks in advance! -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: car...@gm... mail: car...@ya... |
From: Oleg B. <ph...@ma...> - 2005-03-16 09:29:55
|
Hi! On Tue, Mar 15, 2005 at 09:43:27PM -0300, Carlos Ribeiro wrote: > That's my first contribution to a 'SQLObject Cookbook'. Good! The only minor think I want to change - get rid of unicode columns. They require unicode values: john = Person(name=u'John') and the only reason why the examples work is that you used plain 7-bit ASCII, not full 8-bit ISO-8859-1. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Carlos R. <car...@gm...> - 2005-03-16 17:55:39
|
On Wed, 16 Mar 2005 12:29:49 +0300, Oleg Broytmann <ph...@ma...> wrote: > Hi! > > On Tue, Mar 15, 2005 at 09:43:27PM -0300, Carlos Ribeiro wrote: > > That's my first contribution to a 'SQLObject Cookbook'. > > Good! The only minor think I want to change - get rid of unicode > columns. They require unicode values: > > john = Person(name=u'John') > > and the only reason why the examples work is that you used plain 7-bit > ASCII, not full 8-bit ISO-8859-1. :-) I always use Unicode columns because my projects involve working with 'extended' characters in portuguese. I assumed that, as a matter of 'policy', the Cookbook recipes should use Unicode columns unless we could be absolutely sure that the columns would *always* be restricted to 7 bit ASCII characters. But you are right, I forgot the the unicode prefix in the strings :-) btw, do you have any other suggestion on how to handle the 'unique person-role' relationship constraint in the recipes? I thought that there should be a better way to do it, but I dont know how without resorting to a db-specific solution. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: car...@gm... mail: car...@ya... |
From: Oleg B. <ph...@ph...> - 2005-03-16 17:59:01
|
On Wed, Mar 16, 2005 at 02:55:36PM -0300, Carlos Ribeiro wrote: > :-) I always use Unicode columns because my projects involve working > with 'extended' characters in portuguese. I assumed that, as a matter > of 'policy', the Cookbook recipes should use Unicode columns My thought was exactly opposite - always use StringCol in the cookbook. > btw, do you have any other suggestion on how to handle the 'unique > person-role' relationship constraint in the recipes? I have no idea. Both your solutions are ok with me. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Carlos R. <car...@gm...> - 2005-03-16 18:10:04
|
On Wed, 16 Mar 2005 20:58:50 +0300, Oleg Broytmann <ph...@ph...> wrote: > On Wed, Mar 16, 2005 at 02:55:36PM -0300, Carlos Ribeiro wrote: > > :-) I always use Unicode columns because my projects involve working > > with 'extended' characters in portuguese. I assumed that, as a matter > > of 'policy', the Cookbook recipes should use Unicode columns > > My thought was exactly opposite - always use StringCol in the > cookbook. Debatable at best... I read somewhere that the plan for Python is to drop the unicode/string difference and have only one kind of 'character string', that will be unicode based. A new bytes/buffer type will be added to store sequences of bytes transparently (that's one of the uses of strings today). > > btw, do you have any other suggestion on how to handle the 'unique > > person-role' relationship constraint in the recipes? > > I have no idea. Both your solutions are ok with me. > > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ ph...@ph... > Programmers don't die, they just GOSUB without RETURN. > -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: car...@gm... mail: car...@ya... |
From: Oleg B. <ph...@ph...> - 2005-03-16 18:14:55
|
On Wed, Mar 16, 2005 at 03:10:02PM -0300, Carlos Ribeiro wrote: > > My thought was exactly opposite - always use StringCol in the > > cookbook. > > Debatable at best... I read somewhere that the plan for Python is to > drop the unicode/string difference and have only one kind of > 'character string', that will be unicode based. A new bytes/buffer > type will be added to store sequences of bytes transparently (that's > one of the uses of strings today). Then we'll drop UnicodeString, and StrinCol will grow a charset/encoding parameter! (-: Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Ian B. <ia...@co...> - 2005-03-16 18:24:49
|
Oleg Broytmann wrote: > On Wed, Mar 16, 2005 at 03:10:02PM -0300, Carlos Ribeiro wrote: > >>> My thought was exactly opposite - always use StringCol in the >>>cookbook. >> >>Debatable at best... I read somewhere that the plan for Python is to >>drop the unicode/string difference and have only one kind of >>'character string', that will be unicode based. A new bytes/buffer >>type will be added to store sequences of bytes transparently (that's >>one of the uses of strings today). > > > Then we'll drop UnicodeString, and StrinCol will grow a > charset/encoding parameter! (-: Ultimately I think StringCol should support unicode, relying on the database to natively store unicode -- that's contingent both on database unicode support, driver unicode support, and moving to DB-API parameters. UnicodeCol is for supporting Python unicode strings when the database does not (or when any piece of the chain does not). Though I think if StringCol becomes more capable, UnicodeCol will seem redundant and a hinderance to database portability -- for those databases that don't support Unicode (for instance, maybe SQLite will stick with the columns-as-bytes perspective) it would be most convenient to indicate a default encoding for the connection (e.g., 'sqlite:/file?encoding=UTF-8'), and the rest of SQLObject can pretend the database is unicode-aware. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Carlos R. <car...@gm...> - 2005-03-16 18:56:06
|
On Wed, 16 Mar 2005 12:24:24 -0600, Ian Bicking <ia...@co...> wrote: > Ultimately I think StringCol should support unicode, relying on the > database to natively store unicode -- that's contingent both on database > unicode support, driver unicode support, and moving to DB-API > parameters. UnicodeCol is for supporting Python unicode strings when > the database does not (or when any piece of the chain does not). Though > I think if StringCol becomes more capable, UnicodeCol will seem > redundant and a hinderance to database portability -- for those > databases that don't support Unicode (for instance, maybe SQLite will > stick with the columns-as-bytes perspective) it would be most convenient > to indicate a default encoding for the connection (e.g., > 'sqlite:/file?encoding=UTF-8'), and the rest of SQLObject can pretend > the database is unicode-aware. As a side note, I was thinking today about some issues that popped up recently with my usage of SQLObject. It's still a rough draft, a 'half-baked' idea. At the risk of sounding silly, let's share it :-) I have a web framework that is capable of running several 'applications' simultaneously (it's not Rails, but it could be :-). Each application declares its own DB connection and tables. There are a number of issues in this scenario: -- applications can declare tables with the same name, which will cause clashes in the sqlobject registry. I thought about having a separate 'namespace' for each connection. -- the application is multithreaded. How does SQLObject handle the multithreading in this case? Is it safe? One idea that popped up was to use the same 'declarative' style to create DB connections. For example: class myDB(SQLObjectConnection): connectionURI = '...' then I could use: class Person(SQLObject): _connection = myDB Specific connections can be declared also: class myDB(MySQLConnection): user = '...' port = '...' The advantage is that the 'myDB' object would act as a container for several things; for example, it could hold the registry for tables, as a 'per-DB' object. It also could handle multithreading, creating new connections to the database per thread if the backend requires it. And finally, it would be easier to add connection-specific arguments. Is it reasonably, or is it a bad idea? -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: car...@gm... mail: car...@ya... |
From: Scott S. <sc...@st...> - 2005-03-16 19:02:22
|
On Mar 16, 2005, at 10:55 AM, Carlos Ribeiro wrote: > I have a web framework that is capable of running several > 'applications' simultaneously (it's not Rails, but it could be :-). > Each application declares its own DB connection and tables. There are > a number of issues in this scenario: > > -- applications can declare tables with the same name, which will > cause clashes in the sqlobject registry. I thought about having a > separate 'namespace' for each connection. Create a separate registry for each application. This functionality already exists in SQLObject, and I use it. > > -- the application is multithreaded. How does SQLObject handle the > multithreading in this case? Is it safe? I would assume that your DB driver just needs to be thread happy. Scott Sanders |
From: Ian B. <ia...@co...> - 2005-03-16 19:06:40
|
Carlos Ribeiro wrote: > -- applications can declare tables with the same name, which will > cause clashes in the sqlobject registry. I thought about having a > separate 'namespace' for each connection. I'd suggest a separate abstract class for each app, like: class App1SQLObject(SQLObject): _registry = 'app1' _connection = conn1 And then subclassing from that. Realistically this superclass is likely to remain bare enough that it seems kind of redundant, but I can imagine useful things being added to it, like security code or something. (The general pattern is one I adopted from Webware servlets, where it probably makes a bit more sense) > -- the application is multithreaded. How does SQLObject handle the > multithreading in this case? Is it safe? Yes, it's fine. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |