Links to unsaved objects produce malformed link headers

[basho]

Links to unsaved objects produce malformed link headers

[seancribbs]

@nyarly How are you deriving the link? RObject#to_link?

[seancribbs]

Also, please provide a failing test case or snippet of code that reproduces the problem.

[IdahoEv]

It happened in our code when I tried to shovel an associated object with Ripple, and the associated object failed validation. This code snippet reproduces the issue:

class InnerDoc
   include Ripple::Document
   property :foo, String
   validates_presence_of :foo
end
class OuterDoc
   include Ripple::Document
   many :inner_docs
end
o_d = OuterDoc.new
i_d = InnerDoc.new(:foo => nil)
o_d.inner_docs << i_d       # i_d fails validation and so doesn't save, but doesn't raise anything either.  i_d.key == nil.
o_d.save!    # fails with malformed link header b/c od.inner_docs is [i_d], but od.inner_docs.first.key == nil

EDITED: typos and spelling, snippet reproduces the issue.

[seancribbs]

@IdahoEv Thank you. That should make it easier to narrow down.

[IdahoEv]

Ok - as edited, the above code reproduces the issue.

[nyarly]

@seancribbs - Yes, RObject#to_link called by ManyLinkedProxy on save in Ripple.

The original line comes from lib/riak/link.rb:59 in URL.

Still, I'm mostly curious about what cases that URL would be correct. When is it valid to write (or read?) a link to /buckets/bucket_id without a key?

[seancribbs]

@nyarly @IdahoEv Riak will produce a link to the bucket in the Link header, with rel="up". It is valid to accept those, but not to post them back (which is an inconsistency on the Riak side, actually). I see two possible resolutions:

1. Sliently reject links that do not have bucket, key and/or tag.
2. Raise an exception on links that are do not have bucket, key, and/or tag (and aren't the standard "bucket" link).

What seems the most reasonable? Should the check happen before hitting the transport layer (in RObject) or when marshalling (in the transport layer)? Thoughts/arguments welcomed.

/cc @myronmarston @ntalbott @aphyr

[ntalbott]

I definitely vote for option 2, though I'm not sure whether this makes more sense in RObject or the transport layer. I'm leaning towards the latter.

Of course, this whole discussion violates my number one rule for using Riak: DON'T USE LINKS 😄

[IdahoEv]

I likewise vote for #2.

@ntalbott - out of curiosity, what's your concern with links? (In our case, we're not using them directly, they are just how Ripple handles non-embedded associations.)

[ntalbott]

Riak Links have horrid performance characteristics once you get past a (surprisingly small) number of links-per-document. I recommend you rip them out ASAP and replace with something based on 2i. I'm pretty sure that Ripple will be making the switch to 2i as the default non-embedded association type soon for exactly this reason.

[nyarly]

Yeah, +1 for raising an exception.

@seancribbs can you comment on Ripple's direction vis a vis Links versus indexes?

[seancribbs]

@nyarly It is as @ntalbott says, I will be attempting to discourage use of links in future releases (for one-to-many associations).

[bkerley]

Closing; the code for this has moved to Ripple, and we prefer using indexes/2i for associations there.