من یه جمع بندی میخوام بکنم دررابطه با transaction, implicit transaction, autocommit, autobegin, ... و برداشت خودم رو بگم شاید به درد کسی خورد و اگه جاییش فکر میکنید مشکل داره بگید. در رابطه با postgresql صحبت میکنم.
قبل از هر چیزی بگم که کلا تمام statement هایی که تو postgresql هست تو transaction انجام میشن. همشون! حتی read.
https://www.postgresql.org/docs/17/tutorial-transactions.html
> PostgreSQL actually treats every SQL statement as being executed within a transaction. If you do not issue a BEGIN command, then each individual statement has an implicit BEGIN and (if successful) COMMIT wrapped around it.
پس یا transaction داریم یا transaction block داریم.
وقتی autocommit روشن باشه تمام statement ها به صورت مفهومی اینشکلیه:
BEGIN;
statement1;
COMMIT;
BEGIN;
statement2;
COMMIT;
مثلا با psql وصل شید atutocommit روشن هست دیفالت. اگه خاموش باشه میشه:
BEGIN;
statement1;
statement2;
COMMIT;
اگه میخواید چند تا statement رو یکجا توی یک transaction بذارید از BEGIN استفاده میکنید. حتی اگه autocommit روشن باشه باز اونا تو یک transaction قرار میگیرن.
حالا DBAPI یا همون pep 249 تو پایتون چیه؟ همون طوری که wsgi یه استاندارد بود گفت باید وب اپ ها چه استانداردیو رعایت کنن، اینم یه استاندارد برای اینه که درایورها باید چه استانداردی رو رعایت کنن برای کار با دیتابیس. پس مهمه بدونیم درایوری که استفاده میکنیم با pep 249 سازگار هست یا نه. asyncpg سازگار نیست psycopg هست.
این pep میگه باید autocommit درایور ها off باشه دیفالت. پس وقتی داریم درباره رفتارشون صحبت میکنیم باید درایور رو هم ذکر کنیم.
الان با psycopg اگه بیاید بزنیم:
cursor.execute("INSERT ...")
cursor.execute("UPDATE ...")
این سر اجرا کردن اولین execute میاد یه transaction به صورت implicit رو اجرا میکنه! این جا اصلا صحبتی از sqlalchemy نیست. اون کاری نمیکنه، اون یه لاگ مینداره که آقا درجریان باشید یه implicit transaction ای ران شده و ما توشیم. چرا لاگ میندازه؟ چون که sqlalchemy با پیشفرض این pep داره کار میکنه و باهاش سازگاره.
https://docs.sqlalchemy.org/en/21/tutorial/dbapi_transactions.html#committing-changes
You might have noticed the log line “BEGIN (implicit)” at the start of a transaction block. “implicit” here means that SQLAlchemy did not actually send any command to the database; it just considers this to be the start of the DBAPI’s implicit transaction.
این یعنی اگه از asyncpg استفاده کنیم implicit begin نداریم؟ چرا. خود نویسنده sqlalchemy میگه داریم و ما اینو با یه emulation layer انجام میدیم که با باقی کتابخونه سازگار بشه:
https://github.com/sqlalchemy/sqlalchemy/discussions/6864#discussioncomment-1142958
You're probably using asyncpg which means you actually are using such a DBAPI emulation layer, as asyncpg is not by itself a pep-249 library. SQLAlchemy provides an emulation layer that allows it to implicitly begin, as the entirety of the rest of SQLAlchemy is built on this assumption.
اگر تو sqlalchemy ما autobegin روشن باشه (دیفالت) و یه کوئری ای زده باشیم که transaction برامون باز شده باشه و بعد جلوتر بیایم
session.begin()
بزنیم ارور میده میگه already in transaction.
پیشنهاد من اینه که autocommit و autobegin هردو False باشن. هر وقت نیاز داشتیم .begin میزنیم. و خب من پیشنهاد میکنم که sessionmaker یا wrapper ای که برای ساخت session دارید رو inject کنید توی روتر ها نه خود session رو. بعد دیگه باز و بسته کردن session تمام scope ای که باهاش کار میکنید دست شماست. فانکشن های لایه سرویس هم میشه هر چند تا بود داخل یه transaction رانش کرد.
Threadمن یه جمع بندی میخوام بکنم دررابطه با transaction, implicit transaction, autocommit, autobegin, ... و برداشت خودم رو بگم…
47 messages · –- ممنون از توضیحات کاملت سروش جان آیا اینکه ما مجبور میشیم توی تمام کوئری هامون هرچند کوچیک و چند خطی ببریمش زیر یه context manager انتی پترن نیست؟ یعنی مثلا من چندتا روت برا crud دارم برای یه entity که کدشونم بسیار سادس بدون وابستگی به چیزی و حالت uow ندارن. و من باید توی همه روت ها این indent async with session.begin() .... رو داشته باشم. چیز خاصی نیست یا من ذهنم به حالت جنگو عادت کرده حساس شدم :)S - ازینکه گفتی session maker رو اینجکت کنیم بجای خود سشن این بود درسته؟ یعنی این کد کل پیشنهادی بود که دادی: # db/base session_factory: async_sessionmaker[AsyncSession] = async_sessionmaker( bind=engine, expire_on_commit=False, autocommit=False, autobegin=False, ) # deps SessionMakerDep = Annotated[AsyncSession, Depends(session_factory)] @router.post('/login', response_model=TokenResponse) async def login( body: LoginRequest, services: ServicesDep, session_maker: SessionMakerDep, ) -> TokenResponse: async with session_maker() as session, session.begin(): admin = await services.admins.authenticate(body.username, body.password) return TokenResponse(access_token=create_access_token(admin.id))A یه نکته ای هم من اضافه کنم چند بار دیگه هم بحث شده بود کلا اضافه کردن دیپندنسی چیزای اینفرایی و سرویس هایی که در تکنیکالی(و نه بیزنسی) وجودشون اضافه شده رو درست نمیدونم دلایلش هم زیاده ولی مهمترینش اینه یه چیزی داره به سیستم اضافه میشه که وجودش توجیه نداره راه حلشم اینه که یه موجودیت گلوبال یا سینگلتون تعریف کنید مثلا session_maker رو توی همون فایل sqla.py بذارید و یدونه اینستنس ازش بسازید و بیت تمام اپلیکیشن ازش استفاده کنید الان دارید به ازای هر فانکشن کال یه سشن میکر میسازید که لازم نبوده بسازید توی همین مثال شما برای لاگین از نظر منطقی فقط body نیازه بقیش نیاز نیست بهتره که به عنوان پارامتر فانکشن داده نشهS A اینم راهکار داره اگر از مسیر متغیر گلوبال بریم -> patch کردن اگر از مسیر سینکلتون بریم -> mock کردن و این رو قبلا (چند سال پیش) صحبت کرده بودیم این راهکار رو داده بودم اما الان ذهنیتم عوض شده و اینطوریم که تستی که تهش نتیجه گرفتیم دیتابیس رو ماک کنیم اصلا وجودش بنظرم خیلی معنادار نیست و یکم شفاف تر بخوام بگم اصلا غلطهS A ببین اره این که یه لایه بیایم عقب تر خیلی دستمونو باز میکنه راه حل های مختلفی میشه زد حتی برای پیاده سازی شاردینگ اصلا مجبوریم اینکارو بکنیم ولی نکتم اینه اصلا هدف این که دیپندسی پستگرس رو بیاریم توی روتر کار منطقی ای نیست به استدلال مشابه تمام تکنولوژی ها باید بیان توی روتر و نکته بدش اینه که شما اینستنس های متعدیی از session_maker خواهید داشتS S A ببین نکته اول اینه که اصلا چرا داری اورراید میکنی؟ من اخیرا نگاهم اینه نباید اورراید بشه چیو میخوای به چی اورراید کنی؟ معمولا همه تست ها یه جایی برای کانفیگ دارن و یه جایی دارن که بتونیم یسری چیزارو در حد کل سیستم تغییر بدی نه؟ خوب یکی از چیزایی که ممکنه بخوای تغییر بدی همینه حجم کدشم کمه حالا نمیدونم دقیقا ۱ خط میشه یا بیشتر ولی این که ۳ ۴ خط کد کمتر و بیشتر توی پروژه باشه واقعا اهمیتی نداره اینکه فانکشنت پارامتر هاش سر جای خودش باشه خیلی مهم تره
S تقریبا آره. با یکم تفاوت: class DatabaseManager: def __init__: # setup self.session_maker = ... @contextmanager def begin() async with self.session_maker.begin() as db_session: yield db_session db_manager = DatabaseManager(... async def get_db: return db_manager DatabaseT = Annotated[DatabaseManager, depends(get_db)] # inside router: async with db.begin() as db_session: await service1(db_Session...) await service2(db_Session...)- این کد رو نگاه کنید # db/base session_factory: async_sessionmaker[AsyncSession] = async_sessionmaker( bind=engine, expire_on_commit=False, autocommit=False, autobegin=False, ) @asynccontextmanager async def session_scope() -> AsyncGenerator[AsyncSession]: async with session_factory() as session: yield session # deps async def db_session() -> AsyncGenerator[AsyncSession]: async with session_scope() as session: yield session SessionDep = Annotated[AsyncSession, Depends(db_session)] def get_services(session: SessionDep) -> Services: return Services(session) ServicesDep = Annotated[Services, Depends(get_services)] @router.post('/login', response_model=TokenResponse) async def login( body: LoginRequest, services: ServicesDep, session: SessionDep, ) -> TokenResponse: async with session.begin(): admin = await services.admins.authenticate(body.username, body.password) return TokenResponse(access_token=create_access_token(admin.id)) اینجا من نمیتونم session maker رو به عنوان dep بدم. چون توی Services من session رو نیاز دارم. باید قبلش یه session داشته باشم و اینکه توی روت دقت کنید من توی خود services الان session رو دارم. اما باز نیاز دارم session رو inject کنم تا begin کنم حالا من نیاز دارم توی تمام روت هام این دو services و session رو اینجکت کنم. یا اینکه دیپندنسی services رو وردارم و توی خود روت instantiate اش کنم در کل احساس میکنم بد دارم جلو میرمS چیزی که من نوشتم شبیه چیزی که شما نوشتید نیست البته در مورد dependency یه بار دیگه ببینید چیکار کردم. بعد شما کد خودتون رو هم میتونید درستش کنید به شکل های مختلف. یکی اینکه اگه حتما میخواید آبجکت Service بسازید نمیخواد dependency ش کنید. داخل روتر خیلی راحت بعد پاس بدید session رو بهش. چرا dependency هست؟ ولی از اون بهتر چرا آبجکت Service میخواید داشته باشید؟ چرا یه ماژول service با یه سری فانکشن توش نه؟ بدونه آبجکت بدون هیچی. خود ماژول هم namespace فانکشناتون هست. ساده سریع راحت. بعد به فانکشن ها session رو پاس بدیدA X K X K
A X چه state ای رو میخاد ذخیره کنه؟ میتونه ذخیره کنه ولی لزوما دلیل وجودش ذخیره state نیست. مثلا session رو میتونیم به عنوان param بهش بدیم. ریپازیتوری فقط یک لایه abstraction برای چگونگی دریافت دیتا هست. اینکه business layer دیگه به infra کاری نداشته باشه. اینکه دیتا چگونه read یا write میشه یا از database میاد ویا یک فایل csv یا json. بخاطر اینکه business layer خودمون رو خالی از پیچیدگی چگونگی دریافت و ذخیره دیتا نگهداریم ازش استفاده میکنیم. اینکه چطور با توابع پیاده سازی کنیم میگم بهتA X آره اون مثالی که زدم اشتباه بود همینطور که آقا سروش گفتن session خودش مرتبط با data layer هست و پاس دادنش یعنی دوباره داریم وابستگی ایجاد میکنیم بین دو لایه پس یه مثال کاملتر نیازه که استفاده از uow رو هم توضیح بده ولی حقیقتا من این کارو functional انجامش ندادم تاحالا که ببینم چجوریه ولی میشه صدرصد چون به کلاس ربطی نداره. repository pattern یک پترن اشتباه یا بی فایده نیست. این پترن ها ممکنه به تنهایی منطقی نباشن وقتی ما domain model نداشته باشیم و فقط data model داشته باشیم که مستقیما از sqlalchemy base ارث میبره استفاده از repository بخش زیادی از ارزش خودش رو از دست میده چون یکی از دلایل اصلیش جدا کردن domain layer از data layer هست تا ما منطق برناممون رو راحت بدون فکر کردن به اینکه sqlalchemy یا هر orm دیگه چه مشکلاتی داره و چجوری دیتارو read و write میکنه توسعه بدیم و موقع تست کردن بتونیم data layer رو با یک implementation fake جایگزین کنیم و غیره. من دیدم اکثر برنامه نویسها فقط با data model کار میکنن پس برای همین منطقی هست تا repository pattern استفاده نشه اما به معنی تین نیست که یک پترن اشتباه باشه که فقط چون تون java و csharp استفاده میشده تو پایتون هم استفاده میشه. domain model repository pattern unit of work pattern هر کدوم این پترن ها مشکلاتی رو حل میکنند و استفادشون باهم اون ارزش واقعی رو بهشون میبخشه و فقط یک لایه بیهوده abstraction نیستن.A دوست عزیز من یه چند بار نوشتم حرفمو و پاک کردم چون هر طوری بگم خیلی تند حرف زدم و ممکنه شخصی برداشت بشه این جمله هاتون یسری جمله های رایجه و تقریبا همشون اشتباهه و ممکنه نپذیرید اگر مثال خوبی داشتید که اثر مثبتشونو نشون بدید میتونیم صحبت کنیم لطفا هم یه مثال کامل باشه چون هر جایی قبل از شما تا امروز مثال زده ما تا شروع کردیم به نقد کردن هی میگن حالا این که مثالهA S A سبحان جان چند نکته بنظرم میرسه که بگم ۱.روش درست چیزی نیست که بشه از داخل پیام های توی گروه یادش گرفت پس سوال خوبیه ولی از مسیر بدی داری دنبالش میگردی ۲.تو صحبتات ۲ تا جمله خیلی بد داری: روش درست از نظر من چیه که تو بخوای سبک سنگین کنی؟؟! من کی ام که بخوام نظر بدم؟ شما کی ای که بخوای سبک سنگین کنی؟ این روش غیر علمی و نادقیق و فاجعه زاست که یکی برا خودش نظر بده یکی برا خودش سبک سنگین کنه. مسیر علمی و درست تهش اهمیتی نداره که تهش من و شما بپذیریم یا نپذیریمS یه موردی هستش و شما با در نظر نگرفتن اون از مسیر صحبتی که کردم منحرف شدی عزیز. کسی قرار نیست کسی رو قضاوت کنه یا بازخواست کنه و حتی کسی قرار نیست روش درست یا درست ترین رو بگه. شما حرف اون عزیز رو نقض کردی بر پایه و تکیه به یک دانشی نقض کردی، هر چند اون دانش درست یا غلط، گفتم که بیان اش کنی تا دو نفر دیگه هم ادامه اش بدن و گپ و گفت کامپیوتری داشته باشیم، همین.A
M
A اون کسی اینکارو کنه شما ردیس رو هم باید همینکارو کنی چند وقت بعدش rabbitmq یا kafka رو هم همین کارو باید بکنی بعدش click house بعد spark بعد elastic search اونوقت میبینی توی سرویس هات ۶ تا متغیر اولت اصلا بیزنسی نیست بعد یسری از دوستان میان ایده های خلاقانه میزنن میگن اصلا همه رو بذاریم توی یه کانتکس و دچار سیل بحران های بعدی میشن و همه چی برمیگرده به این که یه چیزی یه جایی هست که وجودش منطقی نیست