Calling relationship.inverse.options[:nested] seems to always do the right thing (though it is 2:40am and I'm probably not focusing too well). So I guess, if that is the solution and it works for all cases (I'll do more testing tomorrow), my only remaining question is whether or not appending :nested to the OPTIONS set in the Relationship class is poor form, or if that's an extendable part of DataMapper?
The alternative is something like: class Post ... has n, :comments nested :comments end But putting it directly on the association looked cleaner. Obviously that would break any associations that have conditions on a field called "nested", but that's a pretty wild edge-case. On Jun 27, 1:19 am, Chris Corbyn <[email protected]> wrote: > I'm working on dm-rest-adapter so that we can get it to a point where our > JSON-based commerce system will work with it. Issues were: > > * [FIXED] The current version is XML-only; our API is JSON > * [FIXED] The current version always adds an extension; our URLs are > extensionless > * [WIP] The current version assumes everything is a top-level resource; > many of our resources are nested > * [FIXED] We consider ObjectNotFoundError to be the logical outcome of > calling #get!, or nil with calling #get on resources that produce a 404; the > current adapter raises some undocumented exception type in both cases > * [TODO] The current version reads :field options when fetching a resource, > but does not read them when saving a resource!; we use :field, as this is a > legacy API. > > So I set out to update dm-rest-adapter to fit our needs. It has more or less > turned into a rewrite due to the amount of work that needed doing. > > I have swapped out the home-brewed Connection class to use RestClient > instead. I have so far fixed a number of issues (without breaking backwards > compatibility) and I am just now working on support for nested resources.... > which leads me into my question(s): > > I thought for quite a while about what would be the simplest way for a user > to describe their associations as being nested or not, in a way that is not > all-or-nothing (as is the case with us), and decided that this was the > logical approach: > > class Post > include DataMapper::Resource > > property :id, Serial > .... > has n, :comments, :nested => true > end > > So: > > post = Post.get!(7) # => /posts/7.json > comments = post.comments # => # /posts/7/comments.json > > First question. In order to make that work, I had to add a value to the > OPTIONS set in Relationship, like this: > > DataMapper::Associations::Relationship::OPTIONS << :nested > > Is this a viable option (I was surprised it wasn't frozen, as many things > are), or is there a cleaner way to do this? > > Second question: > > With only the "has n, :comments" side of the relationship defined, the query > (post.comments) contains this relationship, so I can check for :nested and > everything works. But as soon as I define "belongs_to :post" in the Comment > model, DataMapper gives me that relationship instead (still when using > post.comments) and thus I'm unable to reliably check if I should be fetching > a nested resource or just using the top-level URL. Is there a way to > reliably get the association from the parent side of the relationship, since > that's logically where :nested should be set? > > If anybody has tried/used the REST adapter and dropped it due to issues that > I haven't mentioned above, please let me know and I'll try to include fixes > for them (depending on the complexity). Dan mentioned using the Accept: > header, for example, so that has been added, because it required only a minor > code change. -- You received this message because you are subscribed to the Google Groups "DataMapper" 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/datamapper?hl=en.
