Evening on Turbogears (Refactoring doesn't go well...)
Written by
on
in
Knight Errant.
I'm planning to spend tomorrow on the long-term Open Source project for a general ISP billing system. So tonight I reviewed the code and tried to get some refactoring done. Basically I split out the various sub-schemas into separate modules so that it's easier to follow which pieces are logically connected.
But now TurboGears doesn't seem to want to generate the SQL to create the database. I gather it has some assumption that the classes will all be defined in the "model" module? Sigh. Guess I'll be undoing that work tomorrow.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Mike C. Fletcher, the VRPlumber, is a philosopher of design turned computer programmer based in Toronto, Canada. He works primarily in the Python programming language, and maintains a large number of Open Source software packages. You can reach him at: mcfletch@vrplumber.com.
Simon Willison on 08/04/2006 3:56 a.m. #
I imagine you can solve your problem by importing the models from your other modules in to the models.py module that TurboGears is looking at. That should add them to the models.py namespace, and will save you rewriting any code.
Mike Fletcher on 08/04/2006 10:32 a.m. #
I'd imagined that too. In fact, it even works fine as far as running TurboGears goes, so I got all the way through the refactoring before I discovered the problem: tg-admin sql sql no longer recognises the imported classes/tables, it creates a blank SQL file to generate the database.<br />
<br />
I'm seriously considering enhancing PyTable somewhat (to have the automated convenience methods for references) and just dumping SQLObject for that. Will see how I feel in half an hour when I sit down to work on it in earnest.
Ryan Tomayko on 08/04/2006 10:40 a.m. #
Simon's level of class never ceases to impress me. Find me another project lead that takes the time to lend a hand with a competing framework in a situation where he could be saying "Hey, why don't you just ditch that *other* framework and come over to Django." <br />
<br />
You're an inspiration to us all, brother.<br />
elvelind grandin on 08/04/2006 11:39 a.m. #
Did you try using soClasses? it's needed when if you import any classes into model.py. Basicly it's a list of the classes you want to use.
Mike Fletcher on 08/04/2006 3:29 p.m. #
Thanks elvelind! That's exactly the key item I was missing. I wrote a function that produces the list from the imported classes without having to manually specify each one and now the refactored code works as expected.