Jaymon / prom

A PostgreSQL or SQLite orm for Python
MIT License
22 stars 4 forks source link

Field lifecycle methods #175

Open Jaymon opened 6 months ago

Jaymon commented 6 months ago

The field methods like fset etc. are getting more and more complicated, so complicated that it is basically crazy to override them. For example, I've added fvalue and ivalue to normalize the values as they are set into the orm and the db, so I can lowercase the value without overriding the current fset, iset, or similar methods.

The question is should I make it so you can still override the methods but not override the main calling methods? Basically, make fvalue be fset and ivalue be iset and then have external methods that do all the current things but then call all the defined iset things.

I'll have to think about the best way to implement this.

Jaymon commented 5 months ago

I think I should keep all the decorator names the same, but have them set _<METHOD-NAME> that will then get called by the corresponding method if they exist, so:


foo = Field(int)

# this will set fooset into foo._iset
@foo.isetter
def fooset(self, value):
    return value + 1

# foo._iset will get called at the end of foo.iset

So I would modify Field.iset to look something like this:

def iset(self, orm, value):
    # all the normal iset stuff
    if self._iset:
        value = self._iset(orm, value)
    return value

This way I can keep basically the same interface, keep the ever increasing amount of logic in all the lifecycle methods, and still allow easy customization