"Diez B. Roggisch" <[EMAIL PROTECTED]> writes: > I doubt that is doable - there is no way (except maybe from entering > trace-mode and monitor the modules dictionary, so make that an "easy way" and > "doable but difficult") to get the order of declarations. And it would still > require the user to rearange things - not very convenient.
Indeed, but it is one thing that should be done *once* and only once. It isn't needed to be done by the user every time. > However, as the designer has the capability to show the dependency graph, it > shouldn't be too hard to compute the partial ordering on that and spit out > the soClasses-property. Or even do that in sql-object and make it > automatically. And if you have another documenting tool that generate your Python code or if you write it by hand you miss the solution and have to compute it yourself. I find it much more productive to write the classes by hand, since I can control everything I want and I don't need to be going from one screen to the other defining properties. So, in my case, solving the problem in SQL Object would automagically work -- as it would for you in any other tool different than mine -- while doing it inside the Toolbox would just solve the problem for toolbox users. For simple models I can use the toolbox... It is fine. And what if I have hundreds of tables and different schemas (I do have it here working... Today I have more than 110 classes defined in two different projects that share some structure -- and this is eliminating duplicates from both projects). Drawing it on the Toolbox would be overkill. > Alternativel, one could first create tables, and then put the constraints on > them. SQL Object could do that as well. It generated just the DDL for table creation and after creating all tables it would create indexes and constraints. Again, solving it on SQL Object side would be the correct solution to me. > Next thing: circular references and deferred triggers... :) :-) There are no ways to define triggers on the database with SQL Object, AFAIK. It would be great if there was, since it would eliminate a lot of things from the Python code for databases that supported triggers and would check it on Python for databases that didn't... And suddenly I wake up :-) -- 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 -~----------~----~----~----~------~----~------~--~---
