"Ben Sizer" <[EMAIL PROTECTED]> writes:
The error is manifested from within the execution of Turbogears, whether the
website itself or via Toolbox. Ultimately, if TG is going to be based around
this MVC paradigm then it's TG that has to solve the problem of keeping the
'M' consistent. It can certainly do it indirectly via delegation but I
really do think it has to be done somehow.
Since TG is moving towards SQL Alchemy and none of the volunteers has taken
this task, I doubt it will exist for SQL Object...
tg-admin should provide a feature to synchronise this, basically. Models
change; that's a fact of life.
tg-admin is a wrapper to sqlobject-admin here. It does nothing more and
nothing less (I believe nothing less... everything I needed was there).
We are not reinventing the wheel here.
Yes, an error is good, but it should also have a tool to fix this. If TG is
It has the tool to fix this. The problem is that the syntax is not what you
want :-)
going to take responsibility for mapping your initial model to an initial
DB, it should map your revised model to a revised DB.
It does. It just doesn't go from "original" to "revised" without some help.
I don't know of any ORM that does that. Imagine that I split a table in two
and then one of the columns where data existed becomes a foreign key. How
will the ORM create the new table, move data around, drop / alter the old
column (create the new one if the old was dropped), map data back and then
insert all constraints automatically? This isn't always easy to do "by hand"
using bare SQL who can tell how hard it is to create a generic API do to all
that automatically by just adding a new class and changing one line in the old
class?
You're going to add fields, that's just a fact. You cannot anticipate every
field you'll ever need in advance, nor should poor tools ever compel you to
attempt to do so.
This is why one of the approaches you can use with SQL Object is letting it
introspect from your database and create the mapping by itself. So you can
use your ER mapper tool, change the database and go on without touching your
model.
It appears it will only 'do the migration for you' if you've already written
everything required to 'do the migration'. That, in my book, is not 'doing
it for me'. It appears to be nothing like "tg-admin sql create" which does
actually do it for you. Have I misunderstood something?
It is an interface for updates, as I said it can't figure out a lot of things
for you, so you have to guide it. On the other hand, it will help migrating
data from the old version to the new one what might save you lots of typing
and allow very complex decision routes while your schema changes.
I don't have a problem with the mangling, but I do have a problem with
having to remember/look up how it is done, just because adding a simple
field or two to my model requires me to edit my database by hand.
It is automatic when you use it more often. :-)
Yes, probably. Unfortunately I've written more text in this thread than
appears to have been written documenting sqlbuilder.
Do you really think so? The first link on Google for "sqlobject sqlbuilder"
takes me here: http://www.sqlobject.org/module-sqlobject.sqlbuilder.html
Since you said there were no examples, the third link for me is
http://groovie.org/articles/2005/11/01/how-to-use-database-agnostic-sql-in-sqlobject
Another example, from SQL Object's wiki: http://wiki.sqlobject.org/delete.html
And even a kind of tutorial is available there:
http://wiki.sqlobject.org/sqlbuilder.html
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?
You're right, it's probably non-obvious, but I find it astonishing that
people are claiming that they don't need to do this sort of thing. In my day
job I've often had joins of up to 20 tables, and many permutations of those
tables in the reporting. I can't imagine how bad the ORM code would look in
those cases, or how many days it would take to execute.
It isn't slow on a well designed database. Of course if you avoid useless
loops -- selecting only relevant data -- it is much faster. This is why I
have some views and auxiliary tables (aka materialized views) on the
database. Letting the most efficient tool do the job is the better solution
(and it is usually the database itself, not myself writing bare SQL for
everything or an ORM abstraction layer).
Take a look at this example from the SQL Object wiki
(http://wiki.sqlobject.org/usingsqlobjectanintroduction.html):
peeps = Person.select("""address.id = person.id AND
address.zip LIKE '504%'""",
clauseTables=['address'])
I can guarantee that if you avoid joining all those tables and start using
database functions and views you'll get a better performance. Specially
because your database can get a better query plan this way.
If I //wanted// to write PHP you wouldn't see me complaining in this
group every month or two when I give TurboGears another go! :) To be
This is also one of the reasons why you're suffering. Start a simple project
and go on with it to the end. If you start, stop, restart, "restop" then you
will always get stuck because you have to shift paradigms from languages, ORM
mappers, etc.
fair though, my point was more that with PHP or C++, often you go down the
"bare SQL" route, and once you've got a utility function or two to map a row
to a list of objects, life becomes trivial. Yet with an ORM, it seems like
In other words: with C++ or PHP you have to reinvent the wheel for each
application so that you get a consistent mapping for the SQL you'll produce
for that application while we're discussing here a generic ORM that will have
to work with lots of distinct applications. Of course the specific tool will
be easier to use and will probably produce better results. But then you'll
have to make this new layer DB agnostic (you have that with SQL Object),
multi-project (you also have that with SQL Object), documented (this is being
done for SQL Object but it depends on volunteers), etc. so you end up with a
huge project within your own project. (See
http://madgeek.com/Articles/ORMapping/EN/mapping.htm for more features.)
Or you're comparing a generic application for multiple database servers with
proprietary SQL for one and only one database server? If this is true, I
don't see how can this be fair in any sense...
you have to learn all kinds of different ways of getting at the info
(.select? .get? sqlbuilder queries?) and even then you can't easily
aggregate the data together from different objects (which totally wrecks the
relational paradigm). In the trivial cases, it's easier, but in the actual
important cases, I'm finding it quite awkward.
You're suffering an impedance mismatch:
http://en.wikipedia.org/wiki/Object-relational_mapping
http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch
http://www.agiledata.org/essays/mappingObjects.html
--
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
-~----------~----~----~----~------~----~------~--~---
