gizli wrote: > > > > From my understanding, some databases like MySQL does not support > setting language for a particular DB session. Some others, such as > Oracle, allows this. Is this ever considered in SA?
If you are looking for an application wide setting, there is an open-ended API bywhich you can set up any per-connection activities desired within the connection system - it is the PoolListener API which is described in the API documentation. For Oracle, you'd get access to each new connection as its opened and you could establish whatever language settings it allows. If OTOH you are looking for something local to a web request or ORM session, the same API also provides "on connect" events which you could in theory configure based on a thread-local association with the "context" you're working in, or you could ensure that a single Connection is acquired for each context and configure it as needed at that level. But this advice all applies to the general question of setting attributes on connections. With regards to locale support for error messages, reimplementing an "equivalent" feature to Oracle's locale support in pure python to simulate the same feature on other databases which don't offer such a feature is not feasible since every database offers hundreds of error messages which change with each version, and are even reported differently depending on the DBAPI in use to some degree. It really becomes an extension of the general issue of "normalizing error messages", something which gets requested occasionally but which again would be an enormously complex and always buggy feature, requiring constant maintenance and releases on the kind of scale and level that only a commercial entity with full time employees could feasibly handle. > or is our only > option to write SQL code to explicitly pass the language parameter to > a session? Do you guys have a better answer? that would solve your problem for Oracle but not a database like MySQL which doesn't offer such a feature. The bigger issue is that IMO its poor form in most cases to expose database errors to end users, unless your application is intended to expose the database as fully as possible in a server admin application such as phpMyAdmin. Other than that case, you usually would express communication with end user via a datamodel which has specific behaviors and constraints, and a controller/business/service layer which allowed only specific actions (and specific error conditions) to occur. Messaging is then handled using a locale-aware view system which allows you to configure translations for all possible messages in as many languages as you need to support. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to sqlalchemy+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
