<100

are all connections used roughly equally?

Yes. They're balanced.

So it seems like no individual connection will ever go a long time without being used?

The user-session lifetime is on average 120 minutes.

So I was thinking of purging them after that.

Unless the databases suffer a shortage of connections, I think keeping around all connections is reasonable

connections are cheap for both the database and python

It's all postgres, so I doubt the database will suffer :-)

Agreed

Thank M.?

does the postgres driver have automatic timeouts with automatic reconnects?

I wouldn't know. I've just dictated to the devs to use pony.

I believe pony uses psycopg behind the scenes.

Yep, psycopg2

I think it'll be fine

We haven't constrained the timeout settings.

Final question: If the binding is lost either side, do you know if pony tries to rebind/reconnect?

I don't know I'm afraid, you could probably test it by killing postgres, waiting a few minutes then launching postgres again, then try to run a query

"testing determines all truth". I'll do that.

Hi Bjorn! On db.bind(...) Pony opens connection to the database and then store it in a thread-local connection pool. When application code enters db_session and makes a query, Pony takes already opened connection from the pool and use it. After exiting db_session, connection is returned to the pool. If you enable logging, you will see RELEASE CONNECTION message from Pony. It means that the connection is not closed, but was returned to the connection pool. Sometimes connection is closed by database server, for example when database server was restarted. After that a previously opened connection becomes invalid. If such disconnect happens, most probably it was between db_sessions, but sometimes it may happens right during active db_session. Pony is prepared to such situations, and may reconnect to the database in an intelligent matter. If Pony executes a query and receive an error that connection is closed, it check the state of db_session in order to know was any updates already sent to the database during current db_session. If db_session just started, or all queries were just SELECTs, Pony assumes it is safe to re-open connection under the hood and continue the same db_session as if nothing unusual is happened. But if some updates were already sent to the database during active db_session before the previous connection becomes invalid, it means these updates are lost, and it is impossible to continue this db_session. Then Pony throws an exception. But in most cases Pony is able to reconnect silently so application code don't notice anything. If you want to close connection which is stored in the connection pool, you can perform db.disconnect() call. In multi-threaded application this needs to be done in each thread separately

Wow. Thanks. Let me read it twice. ...

Wow x 2. I think we should add this to the docs in https://docs.ponyorm.com/transactions.html#working-with-db-session

under "handling disruptions"

By default pony create db tables with latin1_swedish_ci encoding. I using db.generate_mapping(create_tables=True) snippet. But it this case i cant save unicode strings(python3 strings) for entity type str. What i should to do to resolve this problem?

Wow x 2. I think we should add this to the docs in https://docs.ponyorm.com/transactions.html#working-with-db-session

I agree, we will add this to the docs

By default pony create db tables with latin1_swedish_ci encoding. I using db.generate_mapping(create_tables=True) snippet. But it this case i cant save unicode strings(python3 strings) for entity type str. What i should to do to resolve this problem?

Hmm, this is strange, I think Pony should use UTF8 by default

I think Pony does not specify encoding when creating a table, and use default encoding for the database. When you create a new database, please set UTF8 encoding as default

I think Pony does not specify encoding when creating a table, and use default encoding for the database. When you create a new database, please set UTF8 encoding as default

I cant see anything about creation db( or table) with custom encoding in official documentation. Where it's described?

Pony cannot create a database. Creating database requires admin privileges, and Pony typically connects as a restricted user. It may be dangerous to connect to database from application code using admin privileges. Regarding encoding, previously Pony supported working with custom encoding, but now it assumes the encoding is UTF8. Maybe we can reconsider this

If I create a composite_key(a, b) with postgres, does that imply that an index has also been created on a and b?

ah it seems that postgres creates an index as part of creating the constraint

it was not helping a simple query at all, but an additional index on a made the query fast

my above messages are an example of the risks of doing database performance analysis after only half a cup of coffee.

Hi guys, we released Pony 0.7.3. You can see description here: https://blog.ponyorm.com/2017/10/23/pony-orm-release-0-7-3/

Trying to create some object that have relationships but running into an Attribute is required error

If an attribute is required, you need to assign it durng object initialization. In order to do this, you need to create an object on the other side of relationship earlier, and specify it in constructor arguments of you second object

Hi guys, we released Pony 0.7.3. You can see description here: https://blog.ponyorm.com/2017/10/23/pony-orm-release-0-7-3/

Could you clarify what breaking change there will be in the ORDER BY?

If an attribute is required, you need to assign it durng object initialization. In order to do this, you need to create an object on the other side of relationship earlier, and specify it in constructor arguments of you second object

Let me try

Could you clarify what breaking change there will be in the ORDER BY?

See https://docs.ponyorm.com/api_reference.html#Query.order_by

See https://docs.ponyorm.com/api_reference.html#Query.order_by

It doesn't really says what changed. Only that the other method does what order_by did before

# After the 0.8 release q5 = q.order_by(lambda o: o.customer.name)

@luckydonald So it will be similar to the new where method.

@akozlovsky The @db_session 'ddl' parameter seems not be documented.

@luckydonald So it will be similar to the new where method.

Yes, sort_by (the previous/current order_by behavior) is similar to filter: it works with query result, like filter or map methods in Python. The future order_by will be similar to where: if query looks like select(x.y for x in X) The order_by lambda will receive x, not x.y

In most queries, the generator output the same objects which are iterates over: select(x for x in X if <some condition>) For such queries, there is no difference between current and future order_by behavior, they continue working as before

@luckydonald So it will be similar to the new where method.

My usecase is to order by a column, like select(s for s in Sticker) .order_by(orm.desc(Sticker.date_added)) How does that translate to the new one?

In that query, you iterates over s and then output s too. For such query, nothing is changed, you can continue use order_by

So if I don't use lambdas in order_by, I will be fine?

I use result = Article.select() result = result.sort_by(desc(Article.created_at))This has no lambda, but I think it has to change to sort_by.

So something like the following should not work anymore (from the docs): q = select(o.customer for o in Order) q2 = q.order_by(Customer.name)

Henti, you are right @luckydonald The change is not about lambdas, it is about object we use to ordering. If query looks like select(x.y for x in X) We have two different objects: x and x.y. In release 0.8 order_by will work with x while right now it works with x.y select(x.y for x in X).order_by(Y.a) # now select(x.y for x in X).sort_by(Y.a) # now select(x.y for x in X).order_by(X.b) # starting from 0.8

for queries like select(x for x in X if <condition>), nothing changes

I think I have found a regression in 0.7.3 - TypeError: Attribute RisingProductRecord.current_result has unknown option 'size'

current_result = Required(lambda: Result, size=64)

This is in my local testing with SQLite

Previous version that I had was 0.7.2 and that worked

I looks a bit strange when you set size option for relationship attribute. I think such attribute should automatically take all options from the primary key of the related entity. What is the purpose to set different size than in the related primary key?

I believe it was required in a previous version of Pony, but I removed it and 0.7.2 runs without it

It works without it on Postgres as well

I looked through the docs and can't see a reference to size attribute for foreign key relationships, so it looks like my mistake

I agree that it is better to not have to declare it

I have a git commit from November 2016 where the only change was to add the size=64 attribute, so it seems likely that it was required then

Maybe it was a workaround for some PonyORM bug which was fixed since that

I think that's likely. Can you think what changed in 0.7.3 which means it no longer accents the size attribute?

Maybe it was some refactoring, I'll look and tell you. I don't remember we were doing something specifycally related to this

Yeah, I looked at the diff between the two versions and can't see anything

It was the following fix: https://github.com/ponyorm/pony/commit/de7e7e1317e1cc934b3b6f8c36b18ad7386a2e8d Earlier unknown options for relationship attributes just were ignored silently

ok cool

I'm confident in removing the size attributes then

Maybe it was necessary in some really old PonyORM version

Yep I think so

On < 0.7.3, Pony is doing LIMIT 2 when attributes are passed to .get() when there is a composite key for those attribtues. With 0.7.3 and a composite key, now it seems like there is no LIMIT in the query at all for .get()

Let me check

https://gist.github.com/anonymous/e81aa6b209b94fcf51d74a69c645c06a

those examples are with SQLite

Using: composite_key(asin, country_code)

To me it works correctly: >>> from pony.orm.examples.university1 import * >>> Student.get(gpa=3.5) SELECT "id", "name", "dob", "tel", "gpa", "group" FROM "Student" WHERE abs("gpa" - ?) / coalesce(nullif(max(abs("gpa"), abs(?)), 0), 1) <= 1e-14 LIMIT 2 >>> Student.get(tel='123-456') SELECT "id", "name", "dob", "tel", "gpa", "group" FROM "Student" WHERE "tel" = ? LIMIT 2 >>>

It should omiss LIMIT 2 only if unique key is presented in arguments

Hello! class FiscalNumber(db.Entity): _table_ = '%s_fiscal' % schema if DEBUG else (schema, 'fiscal') id = PrimaryKey(int, auto=True) sign = Required(str) drive = Required(str) document = Required(str) date = Required(datetime) composite_key(sign, drive, document) sales = Set('Sale') for this entity in query FiscalNumber.exists(sign=fs, drive=fn, document=fd) sql look like this SELECT "id", "sign", "drive", "document", "date" FROM "home_fiscal" WHERE "sign" = ? AND "drive" = ? AND "document" = ? LIMIT 2 Why used limit 2 for composite key?

oh. never mind. this fixed in new version

??

Hi, it should be fixed in last version (0.7.3)

Thank you for quick response!

Sure :)

if someone needs a telegram bot that collects information from receipts (only for russia). https://github.com/stsouko/fns this bot is open source.

if someone needs a telegram bot that collects information from receipts (only for russia). https://github.com/stsouko/fns this bot is open source.

Permanent link to the stsouko/fns project you mentioned. (?)

My apologies, but this is one of my "what?"-moments.

I must be doing something wrong.