>> 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,
Thanks for such positive feedback. > but as you are seeing, it's insufficient for what people > actually want to do which is map ORM classes. I presented a description for another use case. > We like to keep these kinds of things as external recipes How do you think about to clarify these approaches a bit more? > 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: I hope that these checks can be reconsidered as usual. > for this feature, we are lacking #1 , #2, #3, #4 and #5 right now. I imagine that similar clarification requests can trigger further software evolution. > in particular, should the construct attempt to create a new Table > object in memory also so that it need not be reflected? Can this aspect result in another software extension? > What kinds of complications might arise, Some “surprises” will occur because of the usual challenges of software development. > can we definitely determine what decisions the database makes > when it creates this table? I am curious on how good the determination of table properties can become. > Will people want to ORM map these classes? I would like to achieve it somehow. > how do we determine the primary keys then, Would any more database developers like to add their concerns and advices for this aspect? > or how do we otherwise provide an API for users to define that? I imagine that adjustments can become interesting also in this area. > 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" ? Does one of these commands belong to the official SQL standard? > Would we build separate constructs for different databases This might be necessary if you would like to support non-standard functionality. https://en.wikipedia.org/wiki/SQL#Interoperability_and_standardization > so that they remain unaffected by each other Will a bit more than the least common denominator become applicable? > and if so how does the ORM use case map to that? I find that temporary tables and corresponding objects are useful in several cases. > 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. How much will these approaches influence the change acceptance for a better API design? > 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 Yes. - I would like to perform data analysis for my needs. > so there is no need to involve the ORM here, I published a few scripts which demonstrate the application of your class library for specific data processing tasks. > so it was not clear what feature of the ORM you were seeking. I hope that this programming interface can shield also me a bit more from challenges because of SQL variations. Selections an be constructed in convenient ways by Python query classes. The data export of computed results into additional tables can become nicer, can't it? > can you perhaps illustrate a code example of what you would like to do ? I could mention a bit more from a concrete example. But I imagine that this does not really matter here at the moment. It find it more important to take run time consequences occasionally better into account. Some computations require then that their results will be stored in new tables. >>> 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. I got the impression (from the descriptions a moment ago) in such a direction. > SQLAlchemy doesn't have this feature right now. Thanks for such an information. I am still curious then how the situation can be improved further. How will database reflection support evolve? https://docs.sqlalchemy.org/en/13/core/reflection.html#limitations-of-reflection 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.
