Jorge Godoy wrote:
"Ben Sizer" <[EMAIL PROTECTED]> writes:
> 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.
I still haven't seen a wheel. All I see is a pointer to someone else's axle with vague instructions on how to attach your own wheels.
> 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?
There are a lot of things in life that are impossible to do perfectly, but that doesn't mean they're not worth doing at all. It might be hard (though not impossible) to deduce the exact changes in the case you've given above, true. But tracking a column's addition is trivial. Amending its type is trivial in many cases. Deleting a non-key column is trivial. Changing a foreign key from one column to another of the same type is trivial. Adding a table is trivial. Changing a column to have a foreign key in that new table is trivial. Support for any or all of this would still be a massive improvement over what is there now.
> 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.
If I don't touch the model, who does? The model needs changing one way or another. I'm a Python programmer, and this is essentially a Python tool. The changes should primarily be to the Python code. If Turbogears wants to attach some magic to that via SQLObject, then it should ensure it doesn't break when I do something trivial and predictable like adding a new variable to an object.
> 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.
http://www.sqlobject.org/sqlobject-admin.html According to that, it doesn't do anything at all yet. That's the documentation you get when you go to sqlobject.org, and click "sqlobject-admin documentation". Why do we integrate shoddily-documented tools into Turbogears? Are we going to avoid adding any documentation for this too, to avoid recreating another non-existent wheel? I mean no offence to Ian and the other contributors who have put hard work into SQLObject, because the code is probably fine, but it's just not well-documented enough to be thrust into a framework like this without someone taking up the slack when it comes to explaining its usage. Turbogears has to assume some responsibility for its dependencies.
> 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
And the first link on SQLObject.org for "sqlbuiler documentation" (sic) is this: http://www.sqlobject.org/SQLBuilder.html With virtually nothing of use on it. But even the page you've dug up out of the source code counts as poor documentation - there are still no examples of usage or return values, except for the esoteric test suite buried at the bottom of the source code.
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
Thank you. It's a shame that open source projects so often need to rely on outside journalists and bloggers to document their software.
> 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.
If the database is normalised, and you have 20 joins, then using SQLObject in the way it's supposedly intended is going to run in quadratic time.
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).
I thought about writing an SQL view here... but then, you're doing 90% of the work you'd have to do in order to use plain SQL anyway. You may gain a bit once you work out how to interface that to SQLObject. But now your code is effectively split across the database and Python, which is not great.
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.
MySQL implements joined views in much the same way it implements joined queries, so this isn't really true.
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.
I don't restart. I'm not sure what you're trying to say here. I just take breaks from working on Turbogears while people start to fill the cavernous void that is the documentation. There comes a point where it is too frustrating to code for 10 minutes, find an undocumented aspect, post on this group, wait a day for a response, code for another 10 minutes, repeat ad infinitum.
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.
Not really. With C++ template functions it's quite easy to have a small function that will populate an object from a database row in one line of code - sure, it's one line per query more than SQLObject, but it's not a significant amount of work.
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...
It may not be a fair comparison. However on the other hand, the average user deploys on one web server with one database. Theoretical portability shouldn't therefore come at the cost of practical utility.
You're suffering an impedance mismatch:
Sure. None of that actually helps though. I have no issues with how to represent object hierarchies, or scope, or anything much on the page you linked to. I have issues with tools that, in programming terms, are as agile as a dead elephant! Changing a single field in an object shouldn't require me to run around writing extra scripts and SQL. -- Ben Sizer --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
