Model select() and save() behavior

The model select() behavior acts strange on the results where specific columns were requested and afterwards the save() is called. This is concerning since it leads to the insertion of duplicated rows.

Here’s an example:

In [5]: from app.models import UserModel

In [6]: UserModel.select().count()
Out[6]: 1L

In [7]: u1 = UserModel.select(UserModel.settings).first()

In [8]: u1.settings
Out[8]: {}

In [9]: u1.settings['editor'] = 'vim'

In [10]: u1.save()
Out[10]: 1

In [11]: UserModel.select().count()
Out[11]: 2L

There are two issues I see here, the first one is the fact that a partial select() returns results with no primary key attached to it (or at least a flag that this result belongs to a row in the database).

The second issue is related to the fact that save() on a model with partial results will still generate a full update/insert including all the columns, where it should be isolated to updating just the selected columns.

Please advise here, I will be happy to help with this if you agree with the concerns from above.

[stas]

@tuukkamustonen certainly my experience is different. I’ve had previous experience where @coleifer would refuse any help and later work on his own to provide the same functionality without any arguments. I would suggest we stop right here trying to prove somebody is being personal against @coleifer. All I care is the future and the quality of this project simply because people depend on it.

Imo, the whole debate here is about the amount of magic we expect from an ORM.

Magic has nothing to do with the fact that the exposed API is not consistent.

The suggested changes would change behavior in a backwards-incompatible manner. Wouldn’t that break people’s implementations? That is the key problem here - not that he was against improving the library. Maybe coleifer could consider this for 3.x, but it doesn’t really feel that big of an issue (if an issue at all, as peewee already provides API to do what you are after here). For 3.x or such, it is simply a matter of taste.

You’re just being nice. The author simply refused all the suggestions and you are trying to speak on his behalf. In the end, this issue is still closed.

[tuukkamustonen]

@stas I’m simply following peewee closely now that I am using it in production (no other bindings). In my opinion, you went quite harsh here. coleifer’s response time to tickets and his attitude to resolving them has been simply outstanding. He tries to keep peewee small and simple, which is understandable considering the scope of the project and him being really the only guy maintaining it.

Imo, the whole debate here is about the amount of magic we expect from an ORM. If you consider peewee’s goal (to be simple and easy to understand), less magic is better. I personally would not expect PK to be returned when I explicitly told peewee to only fetch a single field. If I needed also PK, it’s not that bad writing it into select().

The suggested changes would change behavior in a backwards-incompatible manner. Wouldn’t that break people’s implementations? That is the key problem here - not that he was against improving the library. Maybe coleifer could consider this for 3.x, but it doesn’t really feel that big of an issue (if an issue at all, as peewee already provides API to do what you are after here). For 3.x or such, it is simply a matter of taste.