Closed jgaskins closed 11 years ago
I've got this mostly working locally, except I'm not sure what to do about referenced objects (such as the author
attribute in the above example). My original design for this was pretty shortsighted, I think — it simply stored the id of the referenced object as the attribute on the object to be loaded in with Mapper#load_association!
. The way I ended up implementing it locally has it getting the referenced objects from the DB, but I don't like that idea, since we may not want to load an entire object graph just to find out a few pieces of information about that object.
I still think that load_association
is the best thing to do, but probably unserializing the metadata into some sort of Perpetuity::Metadata
object and letting the load_association!
method grab the class and id from that instead. If I do it right, this could be an idempotent call, simply refreshing the attribute.
Serializing objects into something we can store in the DB is a little tricky at the moment and not at all clean. I think we can clean it up by taking a more generic process:
Mapper#serialize
, when iterating over the attributes to serialize, we ask the DB adapter (Perpetuity::MongoDB
) if it can serialize the class of each one. If it can, we just add it to the hash of attributes.Array
,Set
,Hash
, otherEnumerable
or anything responding toeach
), we need to run this same process over each of the elements.serialize
method on the object.Marshal.dump
it or raise an error.For example, let's say we have an
Article
class that contains some strings, anauthor
(maybe aPerson
orUser
object) and an array ofComment
objects:Let's say the
author
attribute is a reference to a document in another collection while thecomments
array embeds theComment
objects inside the document. When we serialize an article, we want the resulting data to look something like this:The
author
gets serialized as a referenced attribute, so enough information is stored in some metadata hash to be able to recreate it.The
comments
in this case would be configured to be an embedded attribute, so the comments are saved entirely within thearticle
''s serialized representation rather than within theComment
collection.Both the
author
andcomments
attributes would need their respective mapper objects.