"Ben Sizer" <[EMAIL PROTECTED]> writes:
possibly migration cases from one model.py to another right. But why
should Turbogears choke just because I added a line like "newCol =
IntCol()" in there?
It's not TG choking, its SQL Object... But what should be done for a column
that you said is present at the database, requires a value and can't be used
by the application because all of what you said is not true on the database
side?
I agree that it shouldn't choke if you had defined a default value. It
doesn't choke on the reverse situation, i.e., when the column exists on the
database but not on the model.
But with a required and inexistent column? If it was my code I'd like it to
scream as early as possible.
It's not necessarily about project planning, though arguably the main
allure of Python comes from rapid, prototyped development, instead of
reams of UML and entity-relationship diagrams done in advance. You
But even for complex pure python projects you have to plan. And if you have
databases on it you have to plan even more because poor database design kills
a lot of applications out there in the wild world due to extremely bad
performance.
often want to be able to incrementally grow your model as you develop
and the tools should facilitate that. And even if you did have
They do. If you add a new class you can simply tell SQL Object to create them
for you. If you change your model and provide the migration scripts, SQL
Object will do the migration for you. I've written about that earlier here.
SQL Alchemy goes even further on the migration route.
everything planned out in advance, requirements change and live systems
have to adapt. Database schemas change all the time and small changes
are trivial to do under normal development circumstances.
In the wild we are only worried with a few database servers, so writing SQL is
not all that hard. Migrating db schemas with that is very easy. You can even
write some Python code to help depending on how complex were the changes.
One example is an extra table I had to insert in a PHP project earlier
this year. This consisted of creating the table, searching for joins
where it would be used, and adding the relevant extra inner join to
each one. Done in about 30 minutes. Not a single problem. In
Turbogears/SQLObject? Well, I have to add the table in the model, as
well as explicitly note backwards references. But that won't propagate
down to the database, so I have to add the table there too, and hope
that the declarations map across properly, including any magic name
mangling SQLObject is doing behind the scenes. Or I can drop the whole
As the docs say you can customize how you want the mangling to be done. If
you feel more comfortable with a different mangling, then go for it. I find
the actual mangling very simple:
- all tables receive an 's' after the class name (e.g. class Book -> books
table)
- all tables have an 'id' column which is an auto-incremented int by
default but can be a string as well
- all 'camelCased' columns have an underscore and names converted to lower
case so we get 'camel_cased' columns instead
- all foreign keys have the name appended with '_id'
- all of that can be overriden by using the dbName attribute
Things like MultipleJoin are better done by fully specifying what you want,
including intermediate table name and columns on each side.
lot and re-add it, having had to write and execute both export and
import scripts, which is a large waste of time when 99.9% of the data
is going right back in exactly the same tables, unchanged. Then I still
have to go through my code and search for all the special cases I had
to write because SQLObject's 'complex' queries are crippled by design.
You can use SQLObject's sqlbuilder.
(And since when was "SELECT LibraryUser INNER JOIN Loan INNER JOIN Book
WHERE Loan.expiry > Now" complex, anyway? Seems that way with
SQLObject, unless you want the query to run in quadratic time, that is.
See how well that goes down with your local librarian...)
How well do other ORMs adapt to multi-table queries? It is simple when
written directly with SQL (what you can do with DBAPI or with sqlbuilder) but
it isn't a simple concept to map. What should be the resulting class from the
above query? What are the requirements? Can the results be directly
modified?
There are clever tricks that can be used to make this type of thing easier
(e.g. using SQL Object to create VIEWs by supplying the create command or
using properties as it is done with identity classes on a default quickstarted
project using identity).
That's significantly more work than the straight SQL approach I used in
PHP. Is this really progress?
If you are trying to write PHP it will never be.
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears?hl=en
-~----------~----~----~----~------~----~------~--~---
