On Mon, Apr 15, 2019 at 12:22 PM Markus Elfring <markus.elfr...@web.de> wrote: >> >> INSERT FROM SELECT refers to an existing table, yes, > > > This SQL command is already supported by your class library. > > >> >> I mention it because you referred to this construct in one of the stack >> overflow >> answers you mentioned. > > > It was shown that is possible (in principle) to copy some table data by > additional programming with Python code. > > >> https://stackoverflow.com/questions/30575111/how-to-create-a-new-table-from-select-statement-in-sqlalchemy#answer-30577608 > > > Can a variant of the method “CreateTableAs” (which you published on > 2015-06-01) become a standard component of the application programming > interface?
it can, but as you are seeing, it's insufficient for what people actually want to do which is map ORM classes. We like to keep these kinds of things as external recipes until it is crystal clear what built in API should be added that meets at least the following criteria, noting that more criteria may be considered: 1. does everything that people need, that is, the full universe of use cases is discovered and addressed 2. is definitely the best and only way to do the thing that people need 3. works very consistently on at least most backends 4. has very comprehensive test coverage 5. is not such a rare use case that a simple recipe (as given) is not enough for this feature, we are lacking #1 , #2, #3, #4 and #5 right now. in particular, should the construct attempt to create a new Table object in memory also so that it need not be reflected? What kinds of complications might arise, can we definitely determine what decisions the database makes when it creates this table ? Will people want to ORM map these classes? how do we determine the primary keys then, or how do we otherwise provide an API for users to define that? How do we document this, including what do we state as why someone might want to do this? Database support - it is unclear what databases support this or how they do so; for example in SQL Server they seem to have a different syntax entirely (SELECT INTO), how do the capabilities of SELECT INTO differ from "CREATE TABLE AS" ? Would we build separate constructs for different databases so that they remain unaffected by each other and if so how does the ORM use case map to that? There is a lot of effort to be considered when we add things to the library including the very arduous and tedious process of dealing with mistakes in the API design, which occur when we build features where we don't have an absolutely solid understanding of what this use case needs to accomplish. By contrast, by providing recipes, all users can immediately do exactly the thing they need without any issue as far as API compatibility, cross-database compatibility, dealing with shortcomings in the API, etc. > > >> I'm beginning to understand what it is you might want to do. > > > Was any information from my clarification request unclear (at the beginning)? When you stated "I would like to count value combinations in database records", that sounds like you are looking to emit a SQL query of some kind so there is no need to involve the ORM here, so it was not clear what feature of the ORM you were seeking. > > >> The most expedient approach is to use the CreateTableAs construct, >> then reflect the new database table using autoload, > > > I was unsure on how the provided data structures would be determined from a > dynamically generated database table. can you perhaps illustrate a code example of what you would like to do ? > > >> or to build the Table object directly: > > > I would prefer to reuse such functionality from the selected database system > (instead of duplicating it by extra Python code). The examples I've illustrated so far aren't duplications. SQLAlchemy doesn't have this feature right now. > > Regards, > Markus > > -- > SQLAlchemy - > The Python SQL Toolkit and Object Relational Mapper > > http://www.sqlalchemy.org/ > > To post example code, please provide an MCVE: Minimal, Complete, and > Verifiable Example. See http://stackoverflow.com/help/mcve for a full > description. > --- > You received this message because you are subscribed to the Google Groups > "sqlalchemy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sqlalchemy+unsubscr...@googlegroups.com. > To post to this group, send email to sqlalchemy@googlegroups.com. > Visit this group at https://groups.google.com/group/sqlalchemy. > For more options, visit https://groups.google.com/d/optout. -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
