Skip to content
This repository has been archived by the owner on Aug 27, 2023. It is now read-only.

Causes conflict with properties #31

Open
justinoue opened this issue Oct 22, 2015 · 2 comments
Open

Causes conflict with properties #31

justinoue opened this issue Oct 22, 2015 · 2 comments

Comments

@justinoue
Copy link

When using new style class properties, inheriting Model causes a conflict.

I assume this is because all non "_" prefixed class attributes are expected to be Fields.

For example:

from flywheel import Model, Field
class Breakfast(Model):
  meal_id = Field(hash_key=True, data_type=int)
  @property
  def eggs(self):
    return self._eggs

  @eggs.setter
  def eggs(self, value):
    self._eggs = value

  @eggs.deleter
  def eggs(self):
    del self._eggs

  def __init__(self):
    self._eggs = None
    if not self.eggs:
      self.eggs = 'scrambled'


if __name__ == '__main__':
  t = Breakfast()
  print(t.eggs)

This prints None

vs

class Breakfast():
  @property
  def eggs(self):
    return self._eggs

  @eggs.setter
  def eggs(self, value):
    self._eggs = value

  @eggs.deleter
  def eggs(self):
    del self._eggs

  def __init__(self):
    self._eggs = None
    if not self.eggs:
      self.eggs = 'scrambled'


if __name__ == '__main__':
  t = Breakfast()
  print(t.eggs)

this properly prints "scrambled".

I think I can overcome what I intended to do with properties by using custom data types. I just wanted to bring this up.

@stevearc
Copy link
Owner

Yeah, that was a terrible, terrible design decision that I regret greatly. I've already removed that behavior in the 0.5 branch, so it's definitely gone in the next significant release. I'm currently working on migrating everything to use boto3 under the hood, which is the last thing I wanted to get in before releasing it. Unfortunately I don't have a time estimate for when that will be complete :/

If this is enough of a problem for you I could possibly do the 0.5 release now and delay the boto3 migration to 0.6

@justinoue
Copy link
Author

Thanks for the reply. And no need to rush 0.5 out, I was able to do what I needed to do.

My model has some fields I'm encrypting/decrypting with KMS. I started off trying to replicate my kms_attrs gem' behavior. For now I've just gone with handling encryption and decryption on the outside.

Using a custom type I was able to get really close to the behavior I was looking for, but ran into some other issues regarding the KMS context and alias. (Decryption happens during the model load, but it requires other fields from the model, so I couldn't work though the timing on that at the moment.)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants