Hello, Alexander! I want to ask your opinion as co-founder of Pony: what is the best approach to implement multi-language in DB architecture using Pony? Suppose I'm designing a diagram of some CMS, and I have a Document entity with following attributes: title, description, content (omit all unnecessary). All of them should be represented in all languages defined in the system (via Language entity). I see several approaches: 1) To use Json type for such columns, i.e. Document[1].title = {'ru': 'Тестовый документ', 'en': 'Test document'} Pros: - easy to retrieve data w/o joining additional tables Cons: - might not be suitable for content which can store too large data 2.1) To use additional entity like String which related to Language (1:M relation type) and to all of the fields of Document via M:1, i.e.: Document(title=[String(lang='en', value='Test document'), String(lang='ru', value='Тестовый документ')]) Pros: - seems it is most flexible way Cons: - the String entity should contain back-refs to each field of Document (title, description, content). But what if we need to localize another entities, like Template, Chunk, Property etc? I think String definition will be too messy. - more complex select with join, like select((d, t) for d in Document for t in Translation if t.language.code == 'en') - not quite convenient way to access localized strings as in (1) 2.2) To use intermediary entity Translation which encapsulates all of the fields to be localized. Maybe also to use inheritance for particular entities, like DocumentTranslation, PropertyTranslation etc which will add specific attributes if it needed. Pros: - organize messy code of abstract String entity Cons: - the same as in (2.1) 3) To use hardcoded attributes like title_ru, title_en, content_ru, content_en. Pros: - easy access to attributes w/o joining Cons: - not so easy to add new language Maybe I'm missing something? What can you advice? Thank you!

Hi! PonyORM does not support async at this moment. For async applications I suggest you to use something like TortoiseORM instead https://github.com/tortoise/tortoise-orm Currently work on migrations are paused, I hope to resume it a bit later

Hi! PonyORM does not support async at this moment. For async applications I suggest you to use something like TortoiseORM instead https://github.com/tortoise/tortoise-orm Currently work on migrations are paused, I hope to resume it a bit later

You need to be careful then: - only use db_session context manager, not db_session decorator with async code - never call async functions (await foo()) inside db_session

I think it may be overly complex task

You need to be careful then: - only use db_session context manager, not db_session decorator with async code - never call async functions (await foo()) inside db_session

Hi everyone! Could anybody tell usecases in anyio/asyncio - I have a projects where async code is prefered ? And what about migrations ??? It would be nice to have a support of django-like migrations….

https://github.com/yifeikong/aioify

Hi, I haven't been here for a while. I'm currently refactoring an ETL application and looking forward to use PonyORM instead of SQLAlchemy. One thing I have used with SA quite often was the instrospection/reflection feature, which I actually miss in PonyORM. Is there a plan to implement this? Peewee has it's own pwiz as well, but does not support Oracle. Regards, Thomas

Yep. Basically the thing pwiz does. SA uses autoload=True, when defining a Table class.

For an example aioify

Would this be faster than using tortoise-orm? I'm thinking in giving tortoise a go but the benchmarks aren't good for my case... I do alot of filtering and gets

Thank you 😊 as I understood - db_session context manager is synchronized operation. Just thought, but if I write simple convertor from ponyorm form to tortoise-orm for logic and django-orm for migrations.... - but I'm not good at processing ast-trees ... How do you think - is it bad idea ? :-)

this query generates a LEFT JOIN SQL query. If I modify the SQL to use a "normal join", it's 4x faster. is there a way to force pony to use a normal join?

@metaprogrammer ssl certificate expired for docs page

Hi, sorry to bother, but I haven't received any answer yet about the automatically reflect a database. Any updates?

Hi Thomas! There is an incomplete reflection library, but it is for PostgreSQL https://github.com/abetkin/pony-inspect

Another question: is mysql.connector supported or do you still use pymysql oder mysqldb? The one from MySQL seems to be the defact standard.

Right now Pony does not support mysql.connector, hope we can add its support in the future

Hi all! I havent found a way to supress the insert duplicate error, so here is my workaround: def insert_replace(): from pony.orm.sqlbuilding import SQLBuilder func = SQLBuilder.INSERT SQLBuilder.INSERT = lambda *a, **b: ['REPLACE INTO '] + func(*a, **b)[1:]

Is this an upsert implementation?

Is this an upsert implementation?

da

I'm new into pony, can you give an example of how to use this?

I hope we can do it next week

Got it, sounds great

It's not only about setup.py, adding new python support is also about checking if they didnt change something in bytecode and if so - checking that these upadtes doesnt break pony decompiling. But as I know it's okay for 3.9