And you CAN use your own functions: https://docs.ponyorm.com/entities.html#hybrid-methods-and-properties

There is no information about startswith in the first link you gave me.

And about the second link – yes, I know, I said it wouldn't make sense to use my own functions *inside* a query.

I'm sorry if I wasn't clear enough.

Hi Krzysztof! Technically speaking, statswith is not a standalone function, but a method of str class. You are right that the full list of supported methods is missed from documentation. We need to add it. Currently, the following methods can be translated: str.startswith str.endswith str.strip str.lstrip str.rstrip datetime.date datetime.now date.today

That's great, thank you. :-)

And what about other time libraries functions that comply with datetime API? Would it be supported as well?

What do you mean, can you give an example?

Pendulum could be an example: https://pendulum.eustace.io/faq/

Theoretically this is possible, but I do not think that we will be able to add the support of other datetime libraries in the near future, because there are more urgent tasks Speaking of other datetime libraries, support can consist of two separate things: 1) Silent conversion of passed datetime parameter value to correct corresponding database type 2) Support of additional datetime methods For (1) we need to know corresponding database datatype for all supported databases. It may be tricky, for example, to store timezone-aware datetime in SQLite database. For (2) we need to know an equivalent SQL expression for each Python method we want to support, for all supported databases Currently, when working with date and time in Pony, you need to use standard timezone-naive values. It may be better to convert all datetime values to UTC before storing them in database. That way each datetime value will be unambiguous

OK, thank you very much for your support! :-)

You are welcome

Is there any way to generate Entities python code from an existing postgres database?

ponyorm/pony · GitHub https://github.com/ponyorm/pony/tree/orm-migrations/pony/migrate

And i remember that there is a third party lib for postrgre

ponyorm/pony · GitHub https://github.com/ponyorm/pony/tree/orm-migrations/pony/migrate

Permanent link to the file pony/migrate mentioned. (?)

Migrate cannot be helpful here.

Migrate cannot be helpful here.

Yep, i tried it and it generates an only one empty entity xD

In my case on mysql database

You can try this library, it should create entity definitions for simple cases https://github.com/abetkin/pony-inspect

You can try this library, it should create entity definitions for simple cases https://github.com/abetkin/pony-inspect

Permanent link to the abetkin/pony-inspect project you mentioned. (?)

One more question: why isn't it possible to set nullable for a bool type in Diagram Editor? Is it a limitation of one of the database backends, or just a mistake?

For all types except strings, "Optional" means "nullable"

Oh, alright. My bad. 😕

No problem

But as you are already here, can I ask, when the 0.8 version (with migration support) will be released and stable? Do you have any idea?

Unfortunately it's hard to say at this moment. We need to do some major refactoring before, it's hard to esimate how long it will take

Alright, then how safe is it to use orm-migrations at the moment? And will the transition from this branch to 0.8 be smooth?

I think orm-migrations branch should work pretty good for simple cases. The database structure for final migrations release should be the same as in orm-migrations branch. It is possible that the syntax of migration files will change. It this case it should be possible to delete previous migration files, make a new initial migration file with a new syntax and continue using the same database

Okay, thank you very much! Sorry for bothering you with such trivia.

I think, there may be problems with SQLite, so you can try orm-migrations if you use PostgreSQL or MySQL

Good to know, because I'm planning to use SQLite for now. I'll try to avoid migrations for now then, thanks!

Okay, thank you very much! Sorry for bothering you with such trivia.

No problem, mgration status is a typical question for PonyORM, for which I don't have definitive answer yet

But when you'll overcome that, the Pony will became a truly rock-solid option. :-)

*become

Yeah, I think so :)

Sorry to bother you once again, but I believe there is a bug in diagram editor. When an entity A has a Set attribute of entities B, and entity B has entity A as part of its PrimaryKey, entity A has default behaviour of cascade delete set to False. I believe it should be True, because part of PrimaryKey is actually more or less Required as well. You can check it here: https://editor.ponyorm.com/user/freewolny/bug

Besides that, sometimes I encounter a situation when the whole diagram disappears and my tab is just empty, white. Then I have no choice but to refresh it, which causes loss of unsaved changes. I learned the hard way to save it regularly.

I know that's just a helper web app and it's not something you're focused on, but I thought you should know what to fix when you'll have some spare time for it.

There is also a problem with Pony ORM itself, specifically with returning primary keys of an object. Do you have a minute?

Hi, I'm away from computer now, but you can describe it

Alright. Let's consider a following scheme: class A(db.Entity): b = Required('B') c = Required('C') xs = Set('X') PrimaryKey(b, c) class B(db.Entity): id = PrimaryKey(int, auto=True) asses = Set(A) class C(db.Entity): id = PrimaryKey(int, auto=True) asses = Set(A) class X(db.Entity): a = PrimaryKey(A) something = Optional(str)

Let's create some objects: b1 = B() c1 = C() a1 = (b=b1, c=c1)

Let's see what a1 is: >>> a1 A[B[1],C[1]]And what's its primary key: >>> pk_a1 = a1.get_pk() >>> pk_a1 (1, 1)That is indeed correct, and the following works as expected: >>> A[pk_a1] A[B[1],C[1]]

Now let's create a fourth object, of class X this time: x1 = X(a=a1)What is x1? >>> x1 X[A[B[1],C[1]]]Yeah, that is correct. Let's now get its primary key: >>> pk_x1 = x1.get_pk() >>> pk_x1 (1, 1)

It's not correct. Since the primary key of object X is an A object, the primary key of x1 should be a1, or rather primary keys of a1. So the expected value would be ((1, 1),).

Indeed, the following fails: >>> X[pk_x1] TypeError: Invalid count of attrs in X primary key (2 instead of 1)

And returning the primary key as a one-element tuple, as mentioned above, would work: >>> pk_x1_correct = ((1, 1),) >>> X[pk_x1_correct] X[A[B[1],C[1]]]

I know that instead of this we could just use repr(x1) and go from there, but returning primary key should work anyway.

I'm sorry for my elaborated narration.

It just feels easier to explain this way. :-)

Thank you for detailed reporting, I'll check it and write an answer

Hey there 🙂 I’m using this ORM in my code and want to mention - I really like it 🙂 Still I have a question - I’have a many-2-many relation. Is there simple way to delete all from intermediate table ? class User(db.Entity): name = orm.Required(str) tags = orm.Optional('Tag') class Tag(db.Entity): name = orm.Required(str) users = orm.Optional(User) I want to remove all data from user_tag table I know that I can create a UserTag model explicilty. and then to use UserTag.delete() But want to know - is there a way to avoid this. And to do smth like User.tags_model.delete() ? Or to write raw SQL for this ? "DELETE from user_tag" Tnanks!

Hi, if you want to delete all rows from many-to-many table you need to use raw sql, like the following: db.execute("delete from %s" % User.tags.table)

Yes! That’s what I was looking for! 🙂 A little proposition = may be we need to mention this in https://docs.ponyorm.com/queries.html#using-raw-sqlpage ?

Thanks!

Sure. Actually, the code I posted will not work if the table name is a tuple (that is, includes a schema name). Probably we need to add a method for receiving properly quoted table name with all components

Hi

There is a way to "config" the classt to have it's own table even if it has another parent class?

Hi. In Pony all subclasses share the same table. There are three ways to implement inheritance in the relational database. http://www.vertabelo.com/blog/technical-articles/inheritance-in-a-relational-database Pony uses single-table inheritance, because it is faster (as it does not require a join on data retrieving). In the future is is possible to add another types of inheritance to PonyORM, but it is a big amount of work, so I don;t think we will add it soon

In wich way is it faster? i thought large databases had the problem of it's length

maybe i am doing something wrong

i have some behaviour that some classes share

but the only thing they share is that behaviour

python code behaviour on the classes?

In wich way is it faster? i thought large databases had the problem of it's length

*large tables

If classes share only small part of attributes/behavior, (like, updated_at attribute), maybe they should not inherit from the same base class

mmmm

yes, just call out to a common function etc

maybe can i have multiple inheritance? like... class UpdatableTime: updated_at=Required(datetime.datetime) ...... class anotherClass(db.Entity,UpdatableTime): ......

This approach (when some attributes are defined inside a mixin class, but this class doesn't have a specific table and doesn't exist as a separate entity) is called abstract base classes. At this moment Pony does not support abstract base classes, but I think we should add them, it is easier than adding multiple-tables type of inheritance. Right now you need to duplicate attribute in all classes

alright

thanks!

Hello. One more question from me (I'm a PITA, I know): is it possible to check for entity type in query? For example, how can I do such a thing: select(b for b in BaseClass if type(b) == InheritedClass)? The _discriminator_ doesn't work inside a query.

I know that the above doesn't really make sense, because I could just do select(i for i in InheritedClass), but it's needed in more complicated cases.

OK, I found it, it seems like I can do: select(b for b in BaseClass if getattr(b, str(BaseClass._discriminator_attr_).split('.')[1]) == 'InheritedClass') But is there a better way?

I know I could just check for b.classtype, but it might fail if the discriminator is named differently.

Hi Krzysztof! Thanks for bugging me out, I just added support of isinstance in queries: https://github.com/ponyorm/pony/commit/f5e24f2743b4e1a298291a07f74144861b809cb4 Now you can write: select(b for b in BaseClass if isinstance(b, InheritedClass))

It will be included in the next release, you can check out PonyORM from GitHub repository to use it right now

https://github.com/antoyo/tql this looks like it has had some inspiration from Pony