On Oct 27, 10:41 pm, Nels Nelson <[email protected]> wrote: > > 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. :-)
Nobody wants to consume yaml. :) yaml is designed for reading/editing by people, but serialization/deserialization is something usually done by machines. yaml is not a good serialization format, IMO. Besides, with this philosophy, you'll be adding more than just xml, json, and yaml. Maybe a ruby client will want marshal format for speed, and then a client that uses python wants it in pickle format for speed. :) > > 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. This is often an antipattern, at least if you ever need to query on multiple keys/values (e.g. find all books that have bar and foo and not baz in their glossary). Don't do this unless you have no other choice or you'll only be querying on one key/value pair at a time. If you are using PostgreSQL, the best way to handle this situation is using an hstore column. > > 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. Well, if you are using the Sequel plugins, they are specially designed for Sequel objects. With to_yaml, you are getting a generic method. Like I mentioned earlier, you can get something similar with yaml, but it will require a similar approach as the existing Sequel plugins. > 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" I don't follow this. deserialization should happen on retrieval, serialization happens before the SQL query is submitted. If you could provide the code, backtrace, and SQL log, I can attempt to diagnose the issue. > 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. By default, Sequel doesn't select columns from the join table in a many_to_many association, but you can set the :select association option to do so. > 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. That's OK. However, it's better to pastie code and backtraces if you run into problems, as that makes it easier to diagnose what the problem is. Jeremy -- 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.
