>> * Will a bit more code reuse become possible (only on concrete demand)? > > I don't see in what way. You're gonna to implement a mix-in class > that could only be mixed with SQLObject's main class.
I suggest to reconsider also the impression around the word “only”. I imagine that base classes will eventually support wider applications (after a while). > What's the real practical advantage of such a split? * Code separation (and combination depending on your development view). * Would you like to omit the CTAS command class for any special run time configurations? > How would the split make code reuse possible? How do you think about to pass combinations of table names and query objects around? >> * Does such a structure belong to good software design >> and development practices? > > Only in theory. Practice is usually much more complex area. I would be interested for corresponding fine-tuning. > People do SQL denormalization to simplify joins and speed things up. By the way: I am also experienced with data warehouse technology. How much do you distinguish between software evolution around SQL and Python code? > We also trade code simplicity (or at lease consistency) with > theoretical design patterns. Will the interest grow for the application of any more design patterns? Regards, Markus _______________________________________________ sqlobject-discuss mailing list sqlobject-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
