Thank you for the pointers. The main usage of these will be in the UI to map the name of items from/into the users native language. One routine would from the items class call into this translation layer and lookup the names as desired in the specified language (with fall back code if such a translation wasn't provided), and a second routine would provide a list of items (using the specified language) and let the user choose one of them.
Of course, the first application of this will be for the language system, which will need a modified language selection routine that lists the languages in their own language so if the system, so if the system is in an incomprehensible language, you can find the language you know. On 6/6/20 12:24 AM, Mike Bayer wrote: > What's important here is how you would use these classes. that is, > if you want to have them all laid out explicitly, and your code will > do things like " session.query(Table157).all() ", that is, refer to > them explicitly, versus these tables are all part of some kind of > dynamic data structure, like "session.query(tables[table_id])" or > something like that. > > the general pattern for making lots of classes of the same structure, > when you are also using the ORM, is to either use mixins, or to just > create the classes dynamically. > > There's a wiki recipe called "EntityName" that shows this, and I've > just updated / reformatted it to be more or less current: > > https://github.com/sqlalchemy/sqlalchemy/wiki/EntityName > > note the second example that shows declarative with a mixin, and shows > how you can use the type() function to generate new classes > dynamically. Creating new classes in Python is quite open ended. > > > On Fri, Jun 5, 2020, at 10:21 PM, Richard Damon wrote: >> I am working on a project where I am using (and learning) SQLAlchemy (to >> an SQLite database if that matters) where I am seeing the need for a >> number of very similar tables, and would like to follow the DRY (Don't >> Repeat Yourself) principle if possible. >> >> Each of these tables will have 3 fields (actually, a few more, but these >> are the key ones that are of interest) >> >> An Integer Field that is a Foreign Key to another Table (and which table >> it is varies on each of the tables being generated) >> >> A Second Integer Field that is also a Foreign Key, but for all the >> tables this is to the same table (it is in fact specifying a language) >> >> A Third field, which will be a text field. (The name of the item >> specified by the First Field, in the language specified by the second) >> >> >> The first two fields together will be the Primary Key for the table. The >> second and third together will have a unique constraint on them. >> >> I am somewhat new to Python (but an experienced programmer and tend to >> learn fast), and trying to figure out the best way to do this while >> trying to minimize repeated code. >> >> One thought that comes to mind is a base class, but then I have only 1 >> class directly derived from declarative_base, but that class itself >> shouldn't generate a table, doesn't have all the information itself to >> make a table, and I am not sure how to pass down to it the information >> about the variable foreign key. >> >> A second thought that looks promising would be a class decorator for the >> class (looks like it should work, but a bit of work to learn how to >> build that). >> >> Something else I didn't think of ? >> >> There are going to be a collection of routines to do some of the >> generalized work for these tables, taking some sort of description of >> which table to work with, which could be put in the base class, or the >> decorator could just duck type the needed hooks into the class. >> >> -- >> Richard Damon >> -- Richard Damon -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/29d616fe-0144-68f7-81c9-eca5f8707332%40Damon-Family.org.
