oh you would have two columns in those tables: id (primary key) and telegram_id (indexed)

I don't think they are useless as tables, as they allow efficient querying when they are treated as full entities

But it would result in something like CREATE TABLE User id PRIMARY KEY CREATE TABLE Chat id PRIMARY KEY CREATE TABLE State id AUTOINCREMENT, chat_id int REFERENCES Chat(id), user_id REFRENCES User(id) UNIQUE(user_id, chat_id)

If you really don't need to know anything beyond id about User and Chat and it is not necessary to remember all users/chats you have seen then you indeed can just define class State(db.Entity, self.State): id = PrimaryKey(int, auto=True) user_id = orm.Optional(int, index=True) chat_id = orm.Optional(int, index=True) state = orm.Required(str) data = orm.Optional(orm.Json, nullable=True)

@luckydonald what's wrong with that? (apart from it needing telegram_id)

But it would result in something like CREATE TABLE User id PRIMARY KEY CREATE TABLE Chat id PRIMARY KEY CREATE TABLE State id AUTOINCREMENT, chat_id int REFERENCES Chat(id), user_id REFRENCES User(id) UNIQUE(user_id, chat_id)

Meaning I would have to check if User and Chat exists, if not, create user and/or chat, and then create my state

If you really don't need to know anything beyond id about User and Chat and it is not necessary to remember all users/chats you have seen then you indeed can just define class State(db.Entity, self.State): id = PrimaryKey(int, auto=True) user_id = orm.Optional(int, index=True) chat_id = orm.Optional(int, index=True) state = orm.Required(str) data = orm.Optional(orm.Json, nullable=True)

Looks good!

Meaning I would have to check if User and Chat exists, if not, create user and/or chat, and then create my state

user = User.get(id=...) if not user: user = User(id=...) # that's a race condition chat = Chat.get(id=...) if not chat: chat = Chat(id=...) # that's a race condition state = State.get(id=...) if state: state.state = "STATE" state.data = {} else: State(chat=..., user=..., state='STATE', data={}) # that's also a race condition :(

Looks good!

Yep

Yep

I think I'll use that

yeah it depends on whether you get value from having user and chat tables

everything else is a tradeoff around that

Btw, here is my code if you are interested: https://github.com/luckydonald/telestate/blob/deploy2/telestate/contrib/pony.py

Btw, here is my code if you are interested: https://github.com/luckydonald/telestate/blob/deploy2/telestate/contrib/pony.py

Permanent link to the file telestate/contrib/pony.py mentioned. (?)

Truth be told, even with my love for PonyORM, in its current state is really a bad choice for library authors.

Hopefully after the migrations there will soon come a Blueprint functionally, which would make stuff much easier for both the developers of libraries as well as the users of a library using PonyORM Edit: found the relevant ticket: https://github.com/ponyorm/pony/issues/330

Hopefully after the migrations there will soon come a Blueprint functionally, which would make stuff much easier for both the developers of libraries as well as the users of a library using PonyORM Edit: found the relevant ticket: https://github.com/ponyorm/pony/issues/330

Especially if you want to use the provided State table within an existing database.

Hope we can look at blueprints after migrations

https://twitter.com/ponyorm/status/1119632487574056960

https://twitter.com/ponyorm/status/1119632487574056960

https://blog.ponyorm.org/2019/04/20/pony-orm-release-0-7-10/

Speaking of versions: Will migrations be called 0.8.0 or 1.0.0?

I think 0.9

@luckydonald I still don't fully understand why you think it is hard to use plugins defined as in example https://github.com/ponyorm/pony/issues/330#issuecomment-470153594

won't pony become "stable" with a proper 1.0 ?

Probably, so I want to fix all API issues before 1.0

Thanks for 0.7.10 :) I'm just beginning a pony project in py 3.7, so this is very timely.

If migrations will be 0.9, what cool features or refactorings are planned for 0.8?

0.8 is reserved for previous migration branch, I think we should not mix them

ah. So skip 0.8?

I think so

makes sense

@luckydonald I still don't fully understand why you think it is hard to use plugins defined as in example https://github.com/ponyorm/pony/issues/330#issuecomment-470153594

in this approach plugins are isolated (without relations bw plugins and core)

I wrote workaround https://pypi.org/project/LazyPony/ Can this idea be included in the project?

#plugin.py class Table1: t2 = DoubleLink(Required(reverse='t1'), Optional()) # core.py class Table2: pass

this is main diff from class factory approach

I think we can include something like that after migrations

I wrote workaround https://pypi.org/project/LazyPony/ Can this idea be included in the project?

Only problem I see with it is that is uses a static approach, i.e. is a singleton. Didn't know it was this easy, though. I tried implementing something similar before.

Here an idea for the autosave issue. That way users can instantly understand what it does, and turn it off quickly. It could be enabled per default, but that button also warns users that it will save automatically, which might be unexpected.

What if it still autosaves, but you always can revert to any previous state?

In what circumstances auto save is not good?

hi, is there a way to cast a Query result to the table classes?

What do you mean?

In what circumstances auto save is not good?

Yeah, a "tag version" button would work as well, but I want something I can click when I am happy with the result, which I can load back without effort.

what if you want to make a change in that result? it is going to be another branch then

I wanna make sure that I have my "working" state, which is the same state of my source code. I don't wanna store accidential clicking while prototyping.

I wanna make sure that I have my "working" state, which is the same state of my source code. I don't wanna store accidential clicking while prototyping.

that last issue could be worked around by having the option to import PonyORM models, but I guess that's out of scope of this issue here.

I wanna make sure that I have my "working" state, which is the same state of my source code. I don't wanna store accidential clicking while prototyping.

I see so having a tag feature also would work, correct?

You are welcome! :)

🙂 good job!

I'm using pycharm, and in a select(<generator>), it is complaining "Expected 'collections.Iterable', got 'Type[MyEntity]' instead." Is there a way to teach pycharm that this is OK, or that entities are iterable within select()...?

I'm using pycharm, and in a select(<generator>), it is complaining "Expected 'collections.Iterable', got 'Type[MyEntity]' instead." Is there a way to teach pycharm that this is OK, or that entities are iterable within select()...?

Hey Jacob, We were asking the guys from JetBrains about adding Pony support. They told us that the best way to help accommodating resources for this was submitting a request here https://intellij-support.jetbrains.com/hc/en-us# They explained that once they see enough people asking about something, they add this.

ok

Is there already a feature request I can +1?

No, you can create a new issue

There is already a feature request: https://youtrack.jetbrains.com/issue/PY-21741 I will submit a more specific request momentarily.

i'm not a pycharm user, but myabe a plugin sstem exists ?

Yes, there is a plugin system, though I haven't written any yet.

Please vote for this: https://youtrack.jetbrains.com/issue/PY-35584

Please vote for this: https://youtrack.jetbrains.com/issue/PY-35584

👍

hi everybody! what's a good way to deal with large-sized columns? I have a table whose columns including bytea audio in various formats, as well as metadata and relationship info. I was trying to debug why a certain function was so slow, and it turns out that touching the class makes Pony load into memory all the audio binary data, even though during this function (and most of the time) I only need the light text/int columns. I worked around this by segregating the bytea columns to a separate table in a 1-to-1 relationship, but I feel dirty about this (it's a Required:Required 1:1 mapping, i.e. they're actually just extra colums…). is there a more elegant way?

Hi, you can set lazy=True option for attribute https://docs.ponyorm.org/api_reference.html?highlight=lazy#cmdoption-arg-lazy

ooh that sounds better

> By default lazy is set to True for LongStr and LongUnicode and to False for all other types. I wonder if it would make sense to let the default be True for bytes type also? I think most people use bytes to store largeish stuff maybe?

I think about the same, I expected Pony already sets lazy=True for bytes type. I think we can change this. But it can break backward compatibility, as some users use bytes to store short binary data, and even use bytes type for primary key attributes. Maybe instead we can add BLOB type which is similar to bytes, but lazy by default #todo

^This

is transaction management added by defualt for raw Queries? Do we need to manually add @db_session() decorator

Yes, you need to wrap raw queries with db_session too

Yes, you need to wrap raw queries with db_session too

Thanks

how do I call a Postgres procedure/function with parameters... i tried the below code.. but itsn't working db.execute(query, query_args)

I think the following should work: x = 10 y = 20 db.execute("call myprocedure($x, $y)") or db.execute("call myprocedure($x, $y)", {'x': 10, 'y': 20})

for functions: x = 10 y = 20 db.execute("select myfunction($x, $y)")

cool... let me try it... i tried the same except for parameter definition is missing "$" sign

select results from postgres sql is tuple... how to configure to use dictCursor

self.db = Database() self.db.bind(provider=self.provider, user=self.username, password=self.password, host=self.hostname, database=self.database

Currently you can't configure result of db.execute to return DictCursor, but you can use db.get_connection() instead import psycopg2 import psycopg2.extras con = db.get_connection() cur = conn.cursor( cursor_factory=psycopg2.extras.DictCursor) cur.execute("select * from t1 where t1.a > %(x)s", {'x': 123})

yup... but if I get a connection like that.. is the transaction management still taken care if a method has @db_session decorator..

also another question.. documentation states connections are returned back to the connection pool.. how many db connections does it create and can it be configured?

Yes, if transaction wasn't already stared a new transaction will be started automatically before db.get_connection() returns connection

Pony keeps one connection per thread. If your application does not use threads, then just one connection. You can close connection belonging to a current thread by calling db.disconnect()

Is there a way to have a reference to a table with a composite primary key?

Is there a way to unbind a db between tests in pytest?