Jorge Godoy wrote:
"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...
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.
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?
tg-admin should provide a feature to synchronise this, basically. Models change; that's a fact of life.
But with a required and inexistent column? If it was my code I'd like it to scream as early as possible.
Yes, an error is good, but it should also have a tool to fix this. If TG is going to take responsibility for mapping your initial model to an initial DB, it should map your revised model to a revised DB.
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.
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.
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.
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?
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 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.
You can use SQLObject's sqlbuilder.
Yes, probably. Unfortunately I've written more text in this thread than appears to have been written documenting sqlbuilder.
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.
> 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.
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 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 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. -- 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 -~----------~----~----~----~------~----~------~--~---
