Hi there - Answering line by line is not really a good use of either of our time and I apologize that I cannot really work with the lack of specifics presented here, if I can restate the situation, the "CREATE TABLE AS" use case is not very common, and as far as an ORM use case, I have no idea what such a feature would look like. The SQL component of CREATE TABLE AS is very easy to create as a recipe and since it is very idiosyncratic to specific databases there is not a compelling reason to prioritize designing and maintaining a built in construct, but as always, contributors are welcome to propose and assist in implementing specific Core and ORM-level features. Specific proposals and test cases are the most helpful approach.
On Mon, Apr 15, 2019 at 4:15 PM Markus Elfring <markus.elfr...@web.de> wrote: > > >> 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.
