Maybe pony is missing there

Read about hooks

https://pythonhosted.org/PyInstaller/hooks.html

Thanks for the advice! I'll look into that

hello

if I need to use ponyorm entities from several python modules, I need to import these entities in every module, do I understand this correctly?

Yeah

and do I need to use db.bind inside each of these modules?

bind and mapping you use only once.

can I generate mappings inside a function?

I have a code similar to: from . import models def init_db(db): db.generate_mapping(create_tables=True)

and mappings are not generated

looks like I'm only able to use the orm if it is defined at the global context, is there a way to somehow pass context between functions?

It should be possible

Hey, big pony user, just noticed there's a telegram group :)

Hey, big pony user, just noticed there's a telegram group :)

welcome)

Hey, big pony user, just noticed there's a telegram group :)

Hi :D

Are the main authors planning future development on pony's core?

Yes, we are. We need to finish migrations first, because it blocks other tasks.

Great to hear :)

Is the migrations work in progress currently public?

No, but I hope to release it soon. The problem with migrations is that we need to change previous tables to make it compatible with migrations. This requires upgrade of previous tables. After such upgrade it is not possible to use previous version of Pony. So we need to be sure that everything is good

I'm happy to help test this, I have a few projects with reasonably complex pony-created tables.

Not on my live database of course

Good to hear. Give me few days, and I'll release migrations branch to public

👌

Hey Alexander, I guess you are getting a lot on this, using MySQL enums with Pony. I have followed this tutorial: https://mailman-mail5.webfaction.com/pipermail/ponyorm-list/2014-September/000125.html And ended up with this code: https://paste.ofcode.org/Ed2jS3t2pHNeUSdRznuc6R Getting this error: TypeError: Expression UserGroup.Regular has unsupported type 'UserGroup' It happens in extract_vars inside core.py and it probably fails within get_normalized_type_of(UserGroup.Regular). Can you suggest something?

Hi @dereli, I ran your example but encounter some other problems as well. I'll try to analyze it and will answer tomorrow

@akozlovsky, the other problems on my code or some other unexpected issues with Pony? Thanks btw.

No, but I hope to release it soon. The problem with migrations is that we need to change previous tables to make it compatible with migrations. This requires upgrade of previous tables. After such upgrade it is not possible to use previous version of Pony. So we need to be sure that everything is good

Actually, why is it not public?

I thought it would still be in planing phase.

That's why I later crated github.com/luckydonald/pony_up

That's why I later crated github.com/luckydonald/pony_up

Important here for me was some locking mechanism, else 8 clients would start migrating the same steps at the same time. @akozlovsky maybe you guys want to look into that too. It's layed out in the README.

Wow, that's interesting, we will look into it

@akozlovsky, the other problems on my code or some other unexpected issues with Pony? Thanks btw.

I got some other exceptions as well, it seems that converter's methods py2sql and sql2py need some fixes

They were never invoked for me, so I couldn't make sure they're correct. If I can be of any help on that please advise.

I got some other exceptions as well, it seems that converter's methods py2sql and sql2py need some fixes

If you touch code, please add docstrings! Make your code great to read again 👍

They were never invoked for me, so I couldn't make sure they're correct. If I can be of any help on that please advise.

Not a bug but in run() you could use first(), so when you have a lot of users, the query isn't slow

Not a bug but in run() you could use first(), so when you have a lot of users, the query isn't slow

I think select(...).first() and select(...)[:1] produce almost the same query. The difference is in the returning type, the former query returns a single object or None, and the later query returns a list that needs further unpacking

if there is the explicity casting to a list with [😏 wont that stop an SQL LIMIT being included?

[ : ]

If you touch code, please add docstrings! Make your code great to read again 👍

PLEASE DO!

if there is the explicity casting to a list with [😏 wont that stop an SQL LIMIT being included?

Well, that was simple a test code to make Enum's work, no performance required there. Thanks for the hint again.

:)

If you touch code, please add docstrings! Make your code great to read again 👍

We can add it, and even have corresponding pull request, but then the documentation will be duplicated in two different places, the separate repository with documentation in ReST format and docstrings. It can lead to inconsistencies when we fix the main documentation and forget to fix docstring.

We can add it, and even have corresponding pull request, but then the documentation will be duplicated in two different places, the separate repository with documentation in ReST format and docstrings. It can lead to inconsistencies when we fix the main documentation and forget to fix docstring.

Why not slowly switch to generating docs from the docstrings?

We can add it, and even have corresponding pull request, but then the documentation will be duplicated in two different places, the separate repository with documentation in ReST format and docstrings. It can lead to inconsistencies when we fix the main documentation and forget to fix docstring.

Also a lot of functions are not documented.

if there is the explicity casting to a list with [😏 wont that stop an SQL LIMIT being included?

The result of select(...) is an instance of Query object. That object has __getitem__ method which accept slices. So, if you write query = select(...) result = query[:limit] it will add LIMIT section to SQL query. But then the result is just a list, so if you apply [...] to result it will not affect the query

ah yes, good point, like [ :1 ][ 0 ]

Also a lot of functions are not documented.

There are two type of API - an external API for users who just define entities and an internal API for developers who want to write some extensions. At this moment we document the external API but not internal one. At some moment of time we need to document internal one as well, but after that it will be harder to change it.

Would it be possible to have timing of SQL queries when debug mode is turned on? I often find myself timing a bunch of queries when debugging performance issues. For example sql_debug(timing=True)

then after the SQL is printed, also showing the time in milliseconds to execute

Pony already gather such statistics, but don't output it to the log, because the SQL query is printed before execution, not after it (otherwise it would be hard to understand which query caused database exception). You can do the following: db.merge_local_stats() stat = db.global_stats for sql, query_stat in stat.items(): print(sql) print(query_stat.max_time, query_stat.avg_time, query_stat.sum_time, query_stat.db_count, query_stat.cache_count)

Thank you, if that is not in the documentation ,it would be good to add

http://ponyorm.readthedocs.io/en/latest/api_reference.html#QueryStat

It is in API reference, maybe we need to add it to other parts of documentation as well

It is in API reference, maybe we need to add it to other parts of documentation as well

It is not only in the API reference - https://docs.ponyorm.com/database.html#database-statistics

What about pony orm and graphql?

Vitalii Abetkin wrote the initial version of Pony GraphQL API, you can find it here: https://github.com/abetkin/pony_graphql You can ask Виталик for details of how it works

Hey @akozlovsky, I guess you couldn't have time for the Enum problem, maybe you can lead me, and I can dive in and try to work on it during the weekend..

Hi, actually I was able to make code work about half a hour ago. In order to do this it was necessary to change some code inside Pony. We don't develop Pony in a way when new types can be added completely externally without changing Pony code itself, because in order to be completely extensible the code needs to be more complex. I can push my changes to separate branch in our GitHub repository. I don't want to merge them to the main branch ('orm'), because in order to do this we need to add support of other databases as well. Also, be aware that there are some drawbacks in using enums in the database: http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/

thanks a lot, I can use that code for sure.. I will ready the article.. Actually I need this because the DB is already using Enums and the codebase is JS/NodeJS. So I want to make it a bit more compatible.

https://github.com/ponyorm/pony/commit/b278886d32a330d48307efe817aa4dfd8f6cbe21

The code is a bit experimental, some corner cases may not work as expected

Will this - in the long run - allow list type on postgres as well?

yes

This is great 👍

Can someone please explain what the root cause of this kind of error is? UnrepeatableReadError: Phantom object SpyResult[718929855] appeared in collection SpyProduct[2777314].results

It comes in a select query that has been cast to a list, nothing exotic

I get it on a very small percentage of requests, but I can't seem to stop it happening completely

I think it's a normal @db_session

results = select(sr for sr in SpyResult if sr.product == self and sr.date >= datetime.date.today() - datetime.timedelta(days=num_days)).order_by(SpyResult.id)[ : ]

that's the query

You have one-to-many relationship between SpyProduct and SpyResult: SpyProduct.results <-> SpyResult.product. At some moment Pony loads all items of SpyProduct.results collection for specific product. In that case, Pony mark the collection as fully loaded in order to not issue additional queries to database. But then you retrieve another SpyResult object which turns out to be related with the same SpyProduct. It is possible if that SpyResult object was created a moment ago in some concurrent transaction. In that case Pony decided that another transaction modified collection which was considered fully loaded, and it is unsafe to continue working with inconsistent data

Ok, thank you. Is there a way to ignore new objects that have been created in another transaction? Isn't the idea of a transaction to have an isolated view of the system, regardless of what happens in other transactions?

Yes, but PostgreSQL by default does not provide full isolation between transactions. It works on READ COMMITTED isolation level, where you can immediately see results of completed concurrent transactions. You can try to use db_session with serializable=True option, in that case it will provide full isolation at some performance expence. When PostgreSQL works with fully isolated transactions it may throw exception if the achievement of full isolation is not possible

"At some moment Pony loads all items of SpyProduct.results collection for specific product. In that case, Pony mark the collection as fully loaded in order to not issue additional queries to database. " - I turned debug mode on with pony, and I don't see any query that selects all SpyResults, only the specific query I pasted above?

Maybe you do iteration over product.results collection. In that case Pony loads all items into memory

would doing len(product.results) trigger that?

I think it does, as it's not doing COUNT(*)