Saving an object removes all links to its related objects

I trying to repeat a demo tutorial with code:

from remodel.models import Model
from remodel.helpers import create_tables, create_indexes

class Products(Model):
    has_many=('Code',)
    has_one=('Value',)

class Code(Model):
    has_one=('Value',)

class Value(Model):
    belongs_to_many=('Product', 'Code',)

create_tables()
create_indexes()
code=Code.create(code='sample')
code['value'].add(Value.create(value=10))

And this code raises error:

Traceback (most recent call last):
  File "models-test.py", line 18, in <module>
    code['value'].add(Value.create(value=10))
AttributeError: 'NoneType' object has no attribute 'add'

Whats wrong with code?

[linkyndy]

Indeed, I’ve spotted a bug on that part. I wanted to flush related caches, but unfortunately I am also wiping existing descriptors defined on the field handler itself.

I’ll start working on a fix for this issue. Thanks for reporting it!

[linkyndy]

Actually, after more thinking on this, I am inclined to say that the current behaviour is the intended one. Let me explain.

In the above example, we are operating on a Code object. When saving this object, we’re interested in saving fields for this actual object, not also its related objects. This would raise a few concerns, if considered: what happens if the related object is invalid? Should the whole operation fail (so, even the Code object will not be saved)? What happens if that object is already saved/not saved yet?

I admit I’ve borrowed a few concerns from Django’s relationship model, that is, HasMany and HasAndBelongsToMany relations are being updated on assignment, while HasOne and BelongsTo aren’t – not even when the parent object is saved. This is in contrast with other frameworks, such as Ruby on Rails, where a lot more magic is involved. I’ve opted for something closer to Django’s relationship model because it is more straight-forward and the developer controls operations in their entirety (so, no “magic” saves involved).

With this in mind, the above example can be made “right”:

code=Code.create(code='sample')
value=Value.create(value=10) # We need this object to save it after it's being assigned to `code`
code['value']=value # This sets `code_id` on `value`
print(code['value']['value']) # prints 10
value.save() # This ensures `value` is saved with `code_id` set
code.save()
print(code['value']['value']) # prints 10

The difference vs the former example is that previously, value was never saved with code_id set, since this field got set after value was saved (part of its creation). Now, by explicitly saving the value object, we make sure its “ties” to the code object are properly persisted.

This is my view on this specific case, and on remodel’s relationship model. Let me know if that makes sense to you as well, and if not, let’s discuss potential improvements related to this!