SF Markus Elfring <elfr...@users.sourceforge.net> wrote:
> >> So there is no valid use case for parallel generation of tables >> except in particular kinds of multi-tenancy situations. > > I find my use case simple enough (and therefore very valid). > I am going to manage two database tables by corresponding > Python classes with SQLAlchemy services. > > I would appreciate if I can fill these data structures in parallel > without a serial database preparation step (table creation with > repeated meta-data specification). You’d need to implement checks for this concurrency. A create table would need to be preceded by a check to see that it exists, for example, and that would likely need to be mutexed on that name so that no race condition occurs in between the time that the name is checked vs. the create table is emitted. if the mutex is on the database end, then you’d need to use Postgresql’s facilities; pg_advisory_lock() appears to be session level (http://www.postgresql.org/docs/9.1/static/functions-admin.html) , which is probably not sufficient if you are using multiple processes. -- 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 http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
