@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.

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

I must be doing something wrong.

Can you explain a bit what is on screenshot?

I have a scenario that contains Site's

I have a Site that contains Scenario's

The scenario1 is in Site[1].scenarios.

But the lookup "scenario in db.Site[1].scenarios" evaluates to false.

what does set(db.Site[1].scenarios) show?

I must have the wrong variable:

db.Scenario[1] in db.Site[1].scenarios

evaluates correctly.

what does set(db.Site[1].scenarios) show?

{Scenario[1]}

I think we're all good. I probably just need some lunch 😂

:)

Is it possible that Site[1] and scenario on screenshot were from different db_session s?

I think we forgot to check this in __contains__

That is correct

It works only for objects from the same db_session

The scenario was from a previous db_session

Thank you. Next beer is on me.

Typically we forbid to mix objects from dfferent db sessions, but on this case we forgot to do the check

Sure :)

Hi. I have problem with memory. Script takes up 2Gb of RAM after creating 400k Book objects. Is there a way to disable caching for some classes or another solution? https://gist.github.com/Kurbezz/989a8cc82f56f203b6a61e239dbe6c6e

Not your main problem, but you can improve performance by doing author = Author.get(id=a_id)

and for your performance issue, how about batching your calls, so maybe doing 1000 "add" invocations per db_session

id_chunks = chunk(ids, 1000) for id_chunk in id_chunks: add(id_chunk)

code for chunk() https://stackoverflow.com/questions/312443/how-do-you-split-a-list-into-evenly-sized-chunks

Do you have yet another db_session, not displayed in gist code? Only the most outer db_session is taken into account, and inner db_sessions are ignored. The objects are clear out of memory on db_session exit. If you have yet another db_session which wraps all these code, the objects will stay in memory

Also, what version of Pony do you use?

Also, what version of Pony do you use?

0.7.3

Do you have yet another db_session, not displayed in gist code? Only the most outer db_session is taken into account, and inner db_sessions are ignored. The objects are clear out of memory on db_session exit. If you have yet another db_session which wraps all these code, the objects will stay in memory

updated gist

Can you enable SQL logging using set_sql_debug(True) in order to see where GET NEW CONNECTION and RELEASE CONNECTION messages are logged. Is it between each add function call, or just at the beginning and in the end of script execution?

In the updated gist code you have the following lines at the end of the script: temp_db.execute('DROP DATABASE temp;') temp_db.commit()

execute and commit can work inside db_session only. It means that you have some additional db_session which wraps all your script code and holds all the objects

You need to remove that outer db_session

Another (hackish) option is to add the following two lines at the end of add function: commit() rollback() commit() is necessary to save your objects to the database. Typically it is performed implicitly on the exit from the db_session rollback() forces clearing of all objects from the current db_session

Thanks