Since document databases have no strict schema, there's no reason we can't persist every instance variable inside an object without having to specify them explicitly. If we do it this way, all objects would be in the exact same state as they were when we saved them, which makes more sense to me.
Originally, this was the idea behind Perpetuity, that all object state would be saved in MongoDB. I made it explicit because I wanted to be able to customize persistence of certain attributes, such as embedded vs referenced attributes for objects that must be mapped (i.e. the DB cannot innately serialize them) or mapping attributes to different keys (see #15).
This would probably change the mapper DSL somewhat, though. There might be some attributes a user doesn't want to persist for whatever reason and I'm not sure what to do about customizing attribute serialization. Maybe something like the following:
Perpetuity.generate_mapper_for Article do
persist_all embed: [:comments], map: { title: 't', body: 'b', comments: 'c' }
end
The idea here would be that the :embed field would contain a list of attributes that would be embedded within the same document rather than referencing another document and the :map field specifies the mapping between attributes and document keys.
Obviously, if we end up creating an adapter for SQL databases (which I would like to do at some point), those would require explicit declaration of which attributes would be persisted, though maybe we could have a PostgreSQL extension to store additional state in hstore.
Since document databases have no strict schema, there's no reason we can't persist every instance variable inside an object without having to specify them explicitly. If we do it this way, all objects would be in the exact same state as they were when we saved them, which makes more sense to me.
Originally, this was the idea behind Perpetuity, that all object state would be saved in MongoDB. I made it explicit because I wanted to be able to customize persistence of certain attributes, such as embedded vs referenced attributes for objects that must be mapped (i.e. the DB cannot innately serialize them) or mapping attributes to different keys (see #15).
This would probably change the mapper DSL somewhat, though. There might be some attributes a user doesn't want to persist for whatever reason and I'm not sure what to do about customizing attribute serialization. Maybe something like the following:
The idea here would be that the
:embedfield would contain a list of attributes that would be embedded within the same document rather than referencing another document and the:mapfield specifies the mapping between attributes and document keys.Obviously, if we end up creating an adapter for SQL databases (which I would like to do at some point), those would require explicit declaration of which attributes would be persisted, though maybe we could have a PostgreSQL extension to store additional state in hstore.