If you want use object from get_or_create helper, whole code that use it should be wrapped by db_session. Or you should get object again by id.

Right, that makes sense.

Actually I find that I can't use inheritance at all to transfer attributes, even if the previous model inherits from db.Entity. Is this correct?

What do you mean by "transfer attributes"?

class A(db.Entity): foo=Required(str) class B(A): bar=Required(str)I'd expect to have tables A and B, with B supporting foo and bar. I thought your comment about repeating the timestamp field only applied to models inheriting from a non-db.Entity class.

There are several ways to implement inheritance in the database: 1) Each entity class & subclass maps to separate table 2) Each subclass maps to the same table as a parent class Django uses the first approach, and Pony uses the second one. Each of this approaches has benefits and drawbacks. The first way require SQL join to correctly retrieve an object from the database. The second way creates columns which contains NULL for objects which belong to other subclasses. In general, using single table for base class and subclasses is more efficient, because it does not requre SQL joins, which are slow.

Why do you want to use separate tables for A and B classes?

Understood sorry I just noticed that passage in the docs.

Guys, hi. Who knows how: 1) Set db_session at once for all queires (for ex. flask) 2) What is about models inheritance.. Will it work without problem with metaclasses or db connection...?

Hi Maxim! Regarding the first question, you can do the following: @app.before_request def enter_db_session(): orm.db_session.__enter__() @app.teardown_request def exit_db_session(exc): orm.db_session.__exit__(exc and type(exc), exc) I don't fully understand the second question, I think it should work without any problems

thanks, .... I also wanted to do this trick... but when i saw dbsession class i not know what method work perfectly with it...

Second, is for ex .. We have some models... (db.Entity) and fields.... class A(db.Entity): class B(A): ... override somes method or fileds... It will work?

When one entity inherits from another one, they share the same table. You cannot override fields, but you can add some methods. If yo want to have some common methods for unrelated entities, you can define them in mixin and inherit from that mixin too. If you want to override previously defined method, you need to specify mixin first. class MyMixin(object): def __str__(self): ... class MyEntity(MyMixin, db.Entity): ...

I ask.. because when i used peewee .. i had problem with model inheritance... Solutions for it i did not find...It worked but with dirty code style...

Hm... The table is model field? What's if i will use different table via class fields.. ? 3) SQLServer support? Is it work?

1) In Pony, if one entity inherits from another, they share the same table, you cannot override that. For different unrelated entities you can specify _table_ explicitly for each entity 2) SQLServer support is work in progress.

Hm... no? class A: _table = 'asasas' class B(A): _table = 'sdsd' print(B()._table) >sdsd

It will not work. There are several strategies how class inheitance can be mapped to database tables. One way (used in Django) is to have separate table for each class. Another way (used in Pony) is to map all classes inherited from the same entity to a single table, and have optional columns for each inherited class. The first way is not as efficient, beause in order to retrieve an object from the database it requires join of several tables, which is slow operation. In the future we can add first type of inheritance to Pony in order to provide compatibility with Django, but right now it support single-table inheritance

Alexander, Thanks a lot for all. You are the first of communicative guys in this chat ... Where are the others? ?

Alexander, Thanks a lot for all. You are the first of communicative guys in this chat ... Where are the others? ?

He is developer of pony

Lord of the Pony

Alexander, Thanks a lot for all. You are the first of communicative guys in this chat ... Where are the others? ?

we here ?

I am just here to watch pony.

Using pony with postgres, setting size of an id field to 64 changes referencing values from INTEGER to BIGINT but not the fields auto increment SERIAL to BIGSERIAL. Is that intentional, an error just in the editor, or in the ORM as well?

agreed, should be BIGSERIAL it is Pony bug too

There's also smallserial

https://www.postgresql.org/docs/9.6/static/datatype-numeric.html

ok, thanks

How do I ensure my 6+ minutes query does not time out? Has pony a limit there? db.execute('UPDATE "stickermessage" AS "sm" SET "new_sticker" = (SELECT "id" FROM "sticker" WHERE "file_id" = sm."sticker")', dict()

Pony iself does not set any limits for query execution

Hi everyone!

Just a question regarding pony

Is there a way to create a pandas DataFrame by reading directly a pony select( ) object?

Or, alternatively, what would be a good indirect way to do so?

hey Alberto currently the best way is to use the to_dict method of an entity https://docs.ponyorm.com/api_reference.html?highlight=to_dict#Entity.to_dict

here you can find an example https://github.com/ponyorm/pony/issues/72

Thanks a lot! to_dict was what I needed

I created a dictionary for every object in the selection and then joined them in a DataFrame in the way explained here: https://stackoverflow.com/questions/17751626/create-a-pandas-dataframe-from-multiple-dicts

I created a dictionary for every object in the selection and then joined them in a DataFrame in the way explained here: https://stackoverflow.com/questions/17751626/create-a-pandas-dataframe-from-multiple-dicts

Great!

Hi again! I have another question. I'm trying to convert a Python project to a Windows executable file, using PyInstaller. It generates the executable, but when I try to run it, an error occurs, related to pony. The error is: " ImportError: No module named 'pony.orm.dbproviders' " Is there a way to avoid that error? Should I use another tool, like Py2exe, to create the exe file? I have the whole traceback of the error, in case it helps. Thanks in advance for any help you can provide!!

Check if there are any files describing the dependencies to include in the Exe?

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 ]