I'm not sure the latter code is bullet-proof. If some exception like NetworkError arises after commit(), but before redis_enqueue, the object will not be added to queue, but will have updated scheduled attribute value. Also, I don't see how latter code will prevent the error. It may shorten the transaction time and reduce the chance of conflict, but probably it will not prevent it absolutely. Also, operations with Redis should be fast and probably don't have big impact on transaction time. > I think attributes other than scheduled are being changed, so not sure making scheduled volitile would help? If your code snippet is complete, the code reads only two attributes of object: x.id and x.scheduled. x.id is a primary key and cannot be updated, so only attribute that can cause OptimisticError is x.scheduled

OptimisticError can arise only if two different processes access the same attribute of the same object: process 1 read the attribute, process 2 updates the same attribute, and then process 1 tries to update any attribute of the same obect

I wonder if this is two scheduler processes actually running at the same time then, as it uses cron. I think I'm going to try switching it to being a process running under supervisor, that might stop the errors

> redis_enqueue should only ever be run once in a given time period (hours). It may be possible, that when it starts once per hour, it starts in multiple processes at the same time

a slow query seems to have been causing multiple schedulers to run at once. Thanks for your help!

Is there a way to update an attribute, without loading the full model data,for example: x = X[1] x.y = 2

it seems to be a major part of my execution time is loading a lot of data for each instance

What is the type of attribue?

the type i want to update is datetime

there are a lot of Unicode attributes which seem to take a long time to load

At this moment you have three options: 1) You can specify lazy=True option for all string attributes you don't want to load. The drawback is, if you later want to access such attributes they will be loaded one-by-one using separate SQL queries. 2) Maybe the slowdown is caused not by loading string attributes, but by multiple SQL queries. It may be possible to reorganize code to load all objects of the same type in a single query. 3) You can use internal method _get_by_raw_pkval_ to represent object in memory without loading it. Then Pony will not load object attributes from the database until you access any attribute. But you need to be sure that the object is really exists in the database, because Pony will not check it for you: x = X._get_by_raw_pkval_((1,)) x.y = 2

I fixed the typo in the method name

Hi, I want to ask about Pony ORM License . Does it okay if I make a propietary software by using PonyOrm License as a free license under Apache?

Sure

Previously it was dusal licensed (AGPL and commercial), but now it just Apache2

so it's okay

I read it,

I just need to make sure

cause I am developing Point of Sales and I am going to use PonyORM for my commercial products

Is it ready for REAL production? Did anybody make something big and complex with it?

i use pony for multiple projects that have plenty of scale and paying customers

It's a fairly minor part of a complex project really

important for productivity etc, but projects are possible without it

I use RAW SQL in my projects, but I want to migrate by using Pony ORM as well.

What makes you think that Pony ORM doesn't quite ready in Deployment / Production?

So- I'm trying to defnie a date in my models, and 'Required(date)' as it shows on the docs is giving me a NameError. Any idea why that would be?

I'm using datetime with no issues

are you doing any import other that from pony.orm import * ?

yes... you're importing date from datetime because that's the type used... that's my bad

Yes, you got it right :D

If I do the exact same query twice within the same database session, but within different model methods, is the result cached?

def x(self): query() def y(self): query()

instance.x(); instance.y()

If these queries use different generators (even with identical text), then no. To be cached, they need to be based on the same code object: def x(self): query = self._get_query() def y(self): query = self._get_query() def _get_query(self): query = select(x for x in X): return query

ah thank you

is it the same with count() and first() queries?

yes

I think

Is there a direct way to "jsonify" the result from a query?

I want to add it, but at this moment I'm busy with migrations. Right now you can use something like jsonify([obj.to_dict() for obj in query])

Thank you as usual :D

I want to add it, but at this moment I'm busy with migrations. Right now you can use something like jsonify([obj.to_dict() for obj in query])

orm.jsonify()?

I think its Flask.jsonify();

select(<generator>).extract(<hierarchical query>)

https://gist.github.com/anonymous/49f28115700ea3db3a5bd346839ced3f This seems to be "leaking" memory, like before the db_session bug was fixed. Could it be because of the start / stop methods using a db_session? the generate function does a large amount of pony queries, but it should be releasing the cache once exiting. The process is currently using 37GB of memory.

That's after 3 hours of the process running

Maybe the code holds reference to some object from each generate_estimade_data() call, and so prevent garbage collection of db_session data. I think I can change Pony code to remove link from object to session cache upon db_session exit, it may help to garbage collect at least some objects.

We just pushed on github some fixes which should improve garbage collection. So, Matthew, you can try your code again using github version of Pony.

Hello @akozlovsky I've used Pony in the past but I just got back to checking it out again. Its license has changed in the time I left it. Well done for all the hard work.

Thanks for the kind words :)

What would be the easiest way to say to_dict should only return Json compatable types

Ignore that, no longer relavent

We just pushed on github some fixes which should improve garbage collection. So, Matthew, you can try your code again using github version of Pony.

Your avatar has panties on her head. Just wanted to remind everyone about that.

Your avatar has panties on her head. Just wanted to remind everyone about that.

What does it mean for you?

Nothing specific. It's more that condensed boredom lead to creation of this fact.

Ok then.

weird question, how often is the PyPI package updated compared to the GitHub?

PyPi package updated at new release, while GitHub repository updated on each bug fix. Currently Pony releases are irregular, maybe one release per several month

got it- thanks

Do I need to change my MariaDB engine to fix this error? (1071, 'Specified key was too long; max key length is 767 bytes')

No, you just need shorter table or fieled name, I think.

PyPi package updated at new release, while GitHub repository updated on each bug fix. Currently Pony releases are irregular, maybe one release per several month

May be make minor release on each fix like in aiopika lib?

Yeah, the 3rd digit

If you need a specific bug fix, you can easily reference a specific git commit until the next proper release

Release frequency it's a part of "production ready" status

File "/root/app/.env/local/lib/python2.7/site-packages/pony/orm/core.py", line 427, in new_func finally: db_session.exit(exc_type, exc, tb) File "/root/app/.env/local/lib/python2.7/site-packages/pony/orm/core.py", line 396, in exit for cache in _get_caches(): cache.release() File "/root/app/.env/local/lib/python2.7/site-packages/pony/orm/core.py", line 1566, in release cache.close(rollback=False) File "/root/app/.env/local/lib/python2.7/site-packages/pony/orm/core.py", line 1592, in close for obj in cache.objects: TypeError: 'NoneType' object is not iterable

is this a known pony bug?

Did you use strict=True param for db_session?

yes

Yes, this but is known. Fix is already on GitHub. It will be part of next release. You can use GitHub version or do not use this param.

thank you!

No problem

Howdy - just wondering if I'm wrong in noticing there is no way to tick "unsigned" on an int in the online designer tool? Should I create an issue on github?

You are right, we need to fix it

Ok - thanks :)

And thanks for Pony :D

You are welcome :)

Hey, @mr_agb. We fixed all bugs you have mentioned: - incorrect index and foreign key names when schema name is specified for table; - problem with primary key column which is a part of a secondary index. Also now you able explicitly specify fk_name for relationship attributes.

In development version of Pony we added sql_debugging decorator which can be used to enable SQL logging for specific function: @sql_debugging def some_function(): <some queries> Also you can use it as a context manager: with sql_debugging: <some queries> By default it enables logging of SQL queries, but it is possible to use it to suppress SQL logging of some code: with sql_debugging(debug=False): <some queries> When logging is enabled, Pony log SQL queries, but not SQL parameter values, because they can consists sensitive information. Sometimes it may be helpful to log parameter values as well to debug some complex issues. Now you can enable logging of parameters in the following way: with sql_debugging(show_values=True): <some queries> Also, now you can specify sql_debug and show_values flags right for db_session decorator/context manager: @db_session(sql_debug=True, show_values=True) def some_function() ... These features are available on GitHub, and will be part of 0.7.4 release

Also, we plan to deprecate sql_debug function in favor of set_sql_debug function to avoid confusion between sql_debug and sql_debugging names