> Why do you need to serialize entire model instances to xml, json, AND > yaml, BTW?
Good point. :-D I suppose I don't. I was trying to get a handle on the easiest way to serialize the Model instances. Also, I figured, that as long as I'm trying all three formats, I might as well try to make them all at least work so I'd have a comparison. :-/ Probably unnecessary. On the other hand, I've always liked the idea of being able to have clients consume a resource from a restful service in as many formats as possible. Seems like it would eliminate any format demands in a contract. Maybe not. Just a thought. :-) > I noticed you are also serializing the glossary column to yaml. It's > kind of amusing that you are serializing the objects on multiple > levels. Yeah. That *is* pretty amusing. :-) The glossary is a fictional field for this post. It is a temporary hack to implement a conceptual model in my application. I hope to one day normalize the "glossary" field into its own sub-structure. Something like this: "many_to_many :glossary, :join_table => :values, :right_key => :value_id, :right_primary_key => :id" where values basically contain reference values that can be looked up by keyword in the database, and attached as entries on the "Book" entity. I have NO idea how I could get such a relationship to serialize usefully or practically. I am not even sure such an arrangement would be any more useful than the simple serialized Hash hack that I am currently using. Clearly I have not thought this through completely. :-( Still learning. :-) > The yaml loader is not recreating the @deserialized_values instance > variable in the model instance. It should be a hash, but it's > probably not set. I'm having trouble understanding why the YAML dump implementation produces so vastly different output compared to the xml and json outputs. The xml and json format seems to be fairly straightforward and comparable. Also, I'm having problems with deserializing the serialized many_to_many relationship that I included in the to_json/to_xml parameters. Basically, when I do something like, Book.to_json(:include => :chapters) I get some reasonable output, that includes a list of chapters complete with the id and name fields of the chapters. This means that when I attempt to deserialize them, of course Sequel (well, Postgres) complains about duplicate primary keys: ERROR: duplicate key value violates unique constraint "chapter_pkey" This is not surprising. :-) I just wish I could figure out how to serialize the join_table that is making the association. That way, when I deserialize the Book, it would ideally re-create those associations (provided I had first deleted the Book entity that I would be deserializing.) I would go ahead and delete the chapters, too, but the chapters relationship is just an example, and actually means something more general in the application -- this just means that I'd prefer to keep the "chapters" around, but just sever the association when purging the containing entity. However, I recognize that I might be making things too complicated, or going about things the wrong way. I am reluctant to ask for any further help on this when you've already been so accommodating, and these issues are beginning to seem somewhat academic, contrived, and over-generalized. -Nels -- You received this message because you are subscribed to the Google Groups "sequel-talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sequel-talk?hl=en.
