[TurboGears] Re: SQLObject, tg-admin sql create/drop and soClasses

Sun, 06 Aug 2006 20:00:06 -0700

On 8/6/06, Yves-Eric Martin <[EMAIL PROTECTED]> wrote:

Jorge Vargas wrote:
> Actually the problem is a little more complicated then the order, it's a
> weird issue with the fact that references to other tables are strings. the
> people at SQLObject list said a couple of reasons why this is suchs a
> problem. when I talk about it on the list they complain about the
> commandline tool usage :)

What does this mean? I am confused now... Is this a TurboGears or a
SQLObject issue? I looked in the sqlobject-discuss archives but I was
unable to find such a thread. Would you have any pointer?

the problem is the commandline tool of sqlobject, which is call by "tg-admin sql" , It's name is sqlobject-admin. if you check tg's code http://trac.turbogears.org/turbogears/browser/trunk/turbogears/command/base.py#L72 you will see all TG does is redirects.

but then the problem comes because the drop doesn't undestands the soClasses.

Anyway, I hope that's not a case of bucket being passed around. That
makes it very difficult for even motivated people to try to
contribute...

no not at all we found the problem, saw it was in sqlobject and they send it to the sqlobject-admin which at least at that time seem to be missing a maintainer. as for the thread I can't remenber I read/answer both mailing list from my email so I have no direct link to it and the archives are really a problem

Because yes, I'd love to contribute and help fixing this issue: I am
considering the possibility of porting a fairly large application to TG
(~70 entities), building and maintaining an ordered (*) "soClasses"
list with this many interrelated classes does _not_ sound like fun...

the problem is a little complex  as you see in the wiki the soClasses in alpha order fixes *most* cases but it also notes that not all cases. The ammount of tables is not a problem, this seems to be there when make tables have lots of relationships to each other.

(*) In my experience, contrary to what is said in the last entry on
ticket #279, it seems the soClasses list must be ordered by
*dependencies*, and not alphabetically.

yes indeed some people say that each Table should be declare before it is being reference, but that is agains the concept of declaring the references as Strings, because the point of that is exactly that you don't have to care about the order of the tables.

so in summary there is something broken with the algoritm to create tables in sqlobject, that in some complex schemas, breaks as it cycles looking for the ref. So the soClasses was introduced as a workaround for that type of problems which seems to be broken on the drop tables.

please reopen the ticket and post your comments, indeed I don't know why it was close since soClasses is a workaround not a fix. 

PS: with such a large system, would I be better of going with
SQLAlchemy?

it doesn't depends on the size more on how confortable you are with  how much the ORM takes care for you. SA is more flexible some will say less magic and since it doesn't do automatic mapping that kind of errors happen if you code them right not if the library has a problem.

--
Yves-Eric



--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to