On Thu, Apr 18, 2019 at 06:27:00PM +0200, Markus Elfring
<markus.elfr...@web.de> wrote:
> >> * 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).
First, I don't believe they will. SQLObject-the library revolves
around SQLObject-the main class. I don't see what wider application
would be possible. Are going to add something to SQLObject that is not
SQLObject-related? In that case your imagination is better than mine.
Second, I suggest you to reconsider your approach. You've spent a
thousand lines of text. IMO it's time to show us some code. Start small,
a hundred lines of Python would be enough for a start.
> > What's the real practical advantage of such a split?
>
> * Code separation (and combination depending on your development view).
Code separation of what? There is only SQLObject and you're gonna to
extend SQLObject.
> * Would you like to omit the CTAS command class for any special run
> time configurations?
That part of the discussion seems to be meaningless without code to
discuss.
> > How would the split make code reuse possible?
>
> How do you think about to pass combinations of table names
> and query objects around?
I don't think about it. What do you plan to implement?
> >> * 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.
To fine-tune some code you have to have that code, no?
> > 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?
I don't. What is "software evolution around SQL"? And does it matter
in the context of implementing CTAS? I don't want the discussion to
stray far and wide.
> > 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?
You can pack them into the code you're writing.
> Regards,
> Markus
Oleg.
--
Oleg Broytman https://phdru.name/ p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
