[python] Databázový engine ?

[superman]

Já tedy co vím, tak prakticky každá rozumná databáze je thread safe, ale 
ještě jsem se u databází nesetkal s jiným přístupem, než že databázové 
přiojení smí využívat jen thread, který provedl funkci connect. Tedy že 
je možné pracovat se stejnou databází v mnoha threadech, ale každý 
thread se musí zvlášť připojit na databázi a pracovat s vlastním 
spojením k db - nelze connection objekty předávat mezi thready. Tudíž 
ani rozpracované transakce. Ale takto to fungovalo, když jsem psal pro 
C/C++, třeba něco překvapí.

Ono je potřeba si uvědomit, že dokonalý thread safe přístup je nesmírně 
náročný a v podstatě i spotřebovává vysokou režii. Proto neexistuje na 
světě nic, co by bylo dokonale thread safe bez omezení (vyjma 
jednoduchých věcí). Prostě vždy je nějaké omezení.

Jinak ohledně sqlite a thread safe je naprosto zbytečné zatěžovat tuto 
konferenci, protože sám autor na tuto otázku vyčerpávajím způsobem 
odpovídá v sql FAQ, takže při aspoň naprostém minimu snahy od 
dotazovaného se nemuselo muset v této konferenci toto řešit:

http://www.sqlite.org/faq.html#q6

(našel jsem cca za 5 sekund hledání)

Miloslav Ponkrác


Filip Štědrosnký napsal(a):
> Zdravím,
>   měl bych jeden takový dotaz. Pracuji v Pythonu na trochu komplikovanějším
> databázovém systému a potřeboval bych poradit, jaký databázový engine zvolit.
> Může být jak client-server, tak in-process a stačí běžná relační databáze s
> pár typy, žádné objektové hračky nepotřebuji (ale nevadily by). Hlavně
> potřebuji, aby to zvládlo uživatelské funkce (nebo lépe vypočítávané sloupce)
> v Pythonu spouštěné v kontextu procesu, který s databází pracuje (je jen
> jeden). V případě inprocess řešení bych potřeboval, aby bylo thread-safe a
> aby bylo možné používat db z více threadů současně, ideálně včetně více
> rozpracovaných transakcí v různých vláknech. Uvažoval jsem o sqlite3, ale
> tam byl nějaký problém s přístupem z více threadů. Dá se to vůbec nějak
> vyřešit ?
> 
> Předem děkuji za všechny odpovědi,
> regnarg
> 
>