sqlobject-discuss Mailing List for SQLObject (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

>    Depends of the quality of those diagrams.

How do you think about to integrate any known graph generation tool
into the current software build process?

Regards,
Markus

On Mon, Apr 22, 2019 at 08:25:08PM +0200, Markus Elfring <Mar...@we...> wrote:
> > if you create some diagrams that could be included as docs
> > I'd be interesting to see.
> 
> I imagine that a status analysis can help also here.
> How are the chances to publish class collaboration diagrams?

   Depends of the quality of those diagrams. I don't have any special
requirements.

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

>    What are those planned fundamental change?

I would eventually try to derive another class with a few additional ingredients.

> Are you going to restructure the entire SQLObject?

Not directly. - I am unsure if my proposal can trigger more collateral evolution
in related software components.

>> How much explanation would you need for standard presentation functionality?
>
>    Not much. I'm sure I know the basics of UML.

This is good to know.

> The most important thing I know about UML is that it's seldom needed.

The usage popularity can vary over time.

> But if you create some diagrams that could be included as docs
> I'd be interesting to see.

I imagine that a status analysis can help also here.
How are the chances to publish class collaboration diagrams?

Regards,
Markus

On Mon, Apr 22, 2019 at 07:40:27PM +0200, Markus Elfring <Mar...@we...> wrote:
> >    Really? Why?
> 
> The application of the SQLObject software (including a base class with this name)
> grew during the years and it has got the potential for further growth.

   IWBN.

> > You better start coding refactoring your design when needed.
> 
> My preferences for software development methodologies can occasionally be
> different from yours.

   Hard to say. Until now I only saw one small commit from you and even
that was buggy initially.

> I am curious if such communication means will really help here
> when it seems that more fundamental change reluctance can be involved.

   What are those planned fundamental change? Are you going to
restructure the entire SQLObject?

> How much explanation would you need for standard presentation functionality?

   Not much. I'm sure I know the basics of UML. The most important thing
I know about UML is that it's seldom needed. But if you create some
diagrams that could be included as docs I'd be interesting to see.

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

>    Really? Why?

The application of the SQLObject software (including a base class with this name)
grew during the years and it has got the potential for further growth.

>> I would prefer to clarify remaining software development concerns
>
>    Waterfall design is the thing of the past.

Not completely. - There are iterations which can be planned to some degree.

> You better start coding refactoring your design when needed.

My preferences for software development methodologies can occasionally be
different from yours.

>> also with the help of development tools around the unified modelling language.
>
>    Sure, go on. Don;t forget to publish the diagrams and explain what
> they mean in simple words.

I am curious if such communication means will really help here
when it seems that more fundamental change reluctance can be involved.

How much explanation would you need for standard presentation functionality?

Regards,
Markus

On Fri, Apr 19, 2019 at 08:00:10AM +0200, Markus Elfring <Markus.Elfring@> wrote:
> >> I imagine that base classes will eventually support wider applications
> >> (after a while).
> >
> >    First, I don't believe they will.
> 
> I find this view interesting.

   Really? Why?

> > the library revolves around SQLObject-the main class.
> 
> It seems that this information can indicate different software
> design preferences.

   Definitely!

> > I don't see what wider application would be possible.
> 
> I guess that such a view can be adjusted if existing software limitation
> will be reconsidered.

   You guessed wrong. This view can be adjusted with working code but
not with discussions.

> >> * 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.
> 
> I can become concerned that software extensions (like my suggestion)
> can influence run time characteristics of related components
> in undesirable ways.

   After that you can rethink your API or implementation.

   Currently you're trying to optimize non-existing code which is
meaningless. The software engineering rules say: first code, then debug,
then optimize. It's easier to optimize correct code than to correct
optimized code.

> >> Will the interest grow for the application of any more design patterns?
> >
> >    You can pack them into the code you're writing.
> 
> I would prefer to clarify remaining software development concerns

   Waterfall design is the thing of the past. You better start coding
refactoring your design when needed.

> also with the help of development tools around the unified modelling language.

   Sure, go on. Don;t forget to publish the diagrams and explain what
they mean in simple words.

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

>> I imagine that base classes will eventually support wider applications
>> (after a while).
>
>    First, I don't believe they will.

I find this view interesting.

> the library revolves around SQLObject-the main class.

It seems that this information can indicate different software
design preferences.

> I don't see what wider application would be possible.

I guess that such a view can be adjusted if existing software limitation
will be reconsidered.

>> * 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.

I can become concerned that software extensions (like my suggestion)
can influence run time characteristics of related components
in undesirable ways.

>> Will the interest grow for the application of any more design patterns?
>
>    You can pack them into the code you're writing.

I would prefer to clarify remaining software development concerns
also with the help of development tools around the unified modelling language.

Regards,
Markus

On Thu, Apr 18, 2019 at 06:27:00PM +0200, Markus Elfring <Mar...@we...> 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/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

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

On Thu, Apr 18, 2019 at 01:35:45PM +0200, Markus Elfring <Mar...@we...> wrote:
> >> Can additional components become helpful as base classes?
> >
> >    Sure but what is the advantage over a single monolithic class?
> 
> I suggest to reconsider the change granularity.

   Certainly if there will be good arguments in favor of it.

> * 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. What's the real
practical advantage of such a split? How would the split make code reuse
possible?

> * Does such a structure belong to good software design
>   and development practices?

   Only in theory. Practice is usually much more complex area. People do
SQL denormalization to simplify joins and speed things up. We always
trade memory for speed or vice versa. We also trade code simplicity (or
at lease consistency) with theoretical design patterns.

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

>> Can additional components become helpful as base classes?
>
>    Sure but what is the advantage over a single monolithic class?

I suggest to reconsider the change granularity.

* Will a bit more code reuse become possible (only on concrete demand)?

* Does such a structure belong to good software design
  and development practices?

Regards,
Markus

On Thu, Apr 18, 2019 at 08:46:24AM +0200, Markus Elfring <Mar...@we...> wrote:
> > If you're not going to add new methods to the SQLObject main class
> > then what?
> 
> Can additional components become helpful as base classes?

   Sure but what is the advantage over a single monolithic class?

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

>> Would it make sense to construct a command class like “table_creation_from_selection”?
>
>    I cannot answer the question because I don't understand the planned API.

It is just a possible software development (in progress as usual), isn't it?

> If you're not going to add new methods to the SQLObject main class
> then what?

Can additional components become helpful as base classes?

Regards,
Markus

On Thu, Apr 18, 2019 at 08:20:29AM +0200, Markus Elfring <Mar...@we...> wrote:
> >    What do you want to know in these areas?
> 
> Would it make sense to construct a command class like ???table_creation_from_selection????

   I cannot answer the question because I don't understand the planned
API. If you're not going to add new methods to the SQLObject main class
then what?

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

>    What do you want to know in these areas?

Would it make sense to construct a command class like “table_creation_from_selection”?

Regards,
Markus

On Wed, Apr 17, 2019 at 09:15:52PM +0200, Markus Elfring <Mar...@we...> wrote:
> >> * Encapsulation of table creation parameters
> >>
> >> * Determination of generated data structures from the database
> >
> >    What do you want to know in these areas?
> 
> * Which parameters (and corresponding classes) will matter for table creation
>   besides the name (and a query object)?

   ``SQLObject.createTable()`` calls ``connection.createTable()`` which
calls ``connection.createTableSQL()``[1] which uses ``sqlmeta.table`` to
get the table's name, the list of columns from ``sqlmeta.columnList``
and optional ``sqlmeta.createSQL`` for extra SQL.

1. https://github.com/sqlobject/sqlobject/blob/ed64be0ed032055b0a6613fe3051d83a74ded566/sqlobject/dbconnection.py#L566

> * How convenient and safe is the supported database introspection currently?
>   (The documentation seems to be terse on this software area.)

   It's not convenient as it can only get the list of columns for a
table and guess their types.
   It's only safe for the most debugged drivers -- MySQL, PostgreSQL and
SQLite.

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

>> * Encapsulation of table creation parameters
>>
>> * Determination of generated data structures from the database
>
>    What do you want to know in these areas?

* Which parameters (and corresponding classes) will matter for table creation
  besides the name (and a query object)?

* How convenient and safe is the supported database introspection currently?
  (The documentation seems to be terse on this software area.)

Regards,
Markus

>> * Encapsulation of table creation parameters
>>
>> * Determination of generated data structures from the database
>
>    What do you want to know in these areas?

* Which parameters (and corresponding classes) will matter for table creation
  besides the name (and a query object)?

* How convenient and safe is the supported database introspection currently?
  (The documentation seems to be terse on this software area.)

Regards,
Markus

On Tue, Apr 16, 2019 at 04:50:28PM +0200, Markus Elfring <Mar...@we...> wrote:
> >    See http://sqlobject.org/SQLObject.html#class-sqlmeta
> 
> Would you like to continue with the clarification of following
> software design aspects?
> 
> * Encapsulation of table creation parameters
> 
> * Determination of generated data structures from the database

   What do you want to know in these areas?

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

>    See http://sqlobject.org/SQLObject.html#class-sqlmeta

Would you like to continue with the clarification of following
software design aspects?

* Encapsulation of table creation parameters

* Determination of generated data structures from the database

Regards,
Markus

On Tue, Apr 16, 2019 at 02:57:14PM +0200, Markus Elfring <Mar...@we...> wrote:
> >    SQLObject supports 2 kinds of inheritance:
> 
> I am used to a stronger usage of inheritance for powerful software developments.

   Some classes in ORMs are of special kinds as they represent database
tables so inheritance must be used carefully for such classes.

> >    And of course classes can be simply inherited without creating SQL tables.
> 
> This is good to know.
> 
> But my clarification request should deal with intentional table creation
> for computation results from selected database queries.
> How can the specified table name be mapped to an additional Python object
> by an extended application programming interface?

    class MyTable(SQLObject):
        class sqlmeta:
            table = 'my_special_table_name'

   See http://sqlobject.org/SQLObject.html#class-sqlmeta

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

>    SQLObject supports 2 kinds of inheritance:

I am used to a stronger usage of inheritance for powerful software developments.

>    And of course classes can be simply inherited without creating SQL tables.

This is good to know.

But my clarification request should deal with intentional table creation
for computation results from selected database queries.
How can the specified table name be mapped to an additional Python object
by an extended application programming interface?

Regards,
Markus

On Tue, Apr 16, 2019 at 01:10:54PM +0200, Markus Elfring <Mar...@we...> wrote:
> > Ic SQLObject one has classes that correspond to tables:
> 
> Can the class hierarchy grow?

   SQLObject supports 2 kinds of inheritance: see

http://sqlobject.org/FAQ.html#how-does-inheritance-work and

http://sqlobject.org/Inheritance.html

   And of course classes can be simply inherited without creating SQL
tables.

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

>> I would prefer then that corresponding classes will be loaded (or imported)
>> only if the code for such functionality will be used at all finally.
>
>    That's not how SQLObject is structured and intended to be used.

Thanks for this information.

> Ic SQLObject one has classes that correspond to tables:

Can the class hierarchy grow?

>    It'd be best if a pull request or a patch will be accompanied with
> tests and docs.

I tend to check the general change acceptance for some software extensions
before more concrete adjustments.

Regards,
Markus

On Tue, Apr 16, 2019 at 12:50:27PM +0200, Markus Elfring <Mar...@we...> wrote:
> > No, I don't see a reason for a new class. New class could override
> > existing methods but we're talking about new method(s) so
> > why not add them just to SQLObject's main class?
> 
> A command like ???CREATE TABLE??? belongs to the category ???data definition language???
> within SQL.
> I would prefer then that corresponding classes will be loaded (or imported)
> only if the code for such functionality will be used at all finally.

   That's not how SQLObject is structured and intended to be used. In
SQLObject one has classes that correspond to tables:

    class MyTable(SQLObject):
        name = StringCol()

and the classes and their instances are used to query database. One can
create the table with ``MyTable.createTable()`` and query it with
``MyTable.select()``. You cannot split ``SQLObject`` class into plugins
that could be loaded only when needed.

> >>>    SQLObject does some limited introspection.
> >>
> >> Would you like to improve the software situation in this area?
> 
> Will the software documentation be extended also?

   It'd be best if a pull request or a patch will be accompanied with
tests and docs.

> Regards,
> Markus

Oleg.
-- 
    Oleg Broytman            https://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

2003	Jan	Feb (2)	Mar (43)	Apr (204)	May (208)	Jun (102)	Jul (113)	Aug (63)	Sep (88)	Oct (85)	Nov (95)	Dec (62)
2004	Jan (38)	Feb (93)	Mar (125)	Apr (89)	May (66)	Jun (65)	Jul (53)	Aug (65)	Sep (79)	Oct (60)	Nov (171)	Dec (176)
2005	Jan (264)	Feb (260)	Mar (145)	Apr (153)	May (192)	Jun (166)	Jul (265)	Aug (340)	Sep (300)	Oct (469)	Nov (316)	Dec (235)
2006	Jan (236)	Feb (156)	Mar (229)	Apr (221)	May (257)	Jun (161)	Jul (97)	Aug (169)	Sep (159)	Oct (400)	Nov (136)	Dec (134)
2007	Jan (152)	Feb (101)	Mar (115)	Apr (120)	May (129)	Jun (82)	Jul (118)	Aug (82)	Sep (30)	Oct (101)	Nov (137)	Dec (53)
2008	Jan (83)	Feb (139)	Mar (55)	Apr (69)	May (82)	Jun (31)	Jul (66)	Aug (30)	Sep (21)	Oct (37)	Nov (41)	Dec (65)
2009	Jan (69)	Feb (46)	Mar (22)	Apr (20)	May (39)	Jun (30)	Jul (36)	Aug (58)	Sep (38)	Oct (20)	Nov (10)	Dec (11)
2010	Jan (24)	Feb (63)	Mar (22)	Apr (72)	May (8)	Jun (13)	Jul (35)	Aug (23)	Sep (12)	Oct (26)	Nov (11)	Dec (30)
2011	Jan (15)	Feb (44)	Mar (36)	Apr (26)	May (27)	Jun (10)	Jul (28)	Aug (12)	Sep	Oct	Nov (17)	Dec (16)
2012	Jan (12)	Feb (31)	Mar (23)	Apr (14)	May (10)	Jun (26)	Jul	Aug (2)	Sep (2)	Oct (1)	Nov	Dec (6)
2013	Jan (4)	Feb (5)	Mar	Apr (4)	May (13)	Jun (7)	Jul (5)	Aug (15)	Sep (25)	Oct (18)	Nov (7)	Dec (3)
2014	Jan (1)	Feb (5)	Mar	Apr (3)	May (3)	Jun (2)	Jul (4)	Aug (5)	Sep	Oct (11)	Nov	Dec (62)
2015	Jan (8)	Feb (3)	Mar (15)	Apr	May	Jun (6)	Jul	Aug (6)	Sep	Oct	Nov	Dec (19)
2016	Jan (2)	Feb	Mar (2)	Apr (4)	May (3)	Jun (7)	Jul (14)	Aug (13)	Sep (6)	Oct (2)	Nov (3)	Dec
2017	Jan (6)	Feb (14)	Mar (2)	Apr	May (1)	Jun	Jul	Aug (1)	Sep	Oct (4)	Nov (3)	Dec
2018	Jan	Feb (1)	Mar	Apr	May	Jun (1)	Jul	Aug	Sep	Oct	Nov	Dec
2019	Jan	Feb (1)	Mar	Apr (44)	May (1)	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec (1)
2020	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec (1)
2021	Jan	Feb (1)	Mar	Apr	May	Jun (3)	Jul	Aug	Sep	Oct	Nov	Dec
2022	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec (1)
2023	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct (1)	Nov (2)	Dec
2024	Jan	Feb	Mar	Apr (4)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (1)
2025	Jan	Feb (1)	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec

sqlobject-discuss Mailing List for SQLObject (Page 2)

SQLObject is a Python ORM.

sqlobject-discuss — All things SQLObject-related