I guess there would be several ways to serialize a CAS. The naive way would be to transport it as a string (i.e. "1234566"); however I'm personally not a fan of putting things as strings unless absolutely necessary; an alternative would be to serialize it as a two element array of integers (i.e. uint32_t) whose sum will form the uint64_t for the CAS; thus a cas of 7 would be [3,4]. This is a more failsafe way of ensuring the CAS stays opaque while also remaining serializable. We could also enforce hexadecimal representation in the string format, etc. etc (i.e. "0xf00f1e"). Just thoughts.
Or we could end up supporting all of the above. I'll wait for Brett to respond to this and see what he has to say :) Mark On Apr 30, 2014, at 7:47 AM, Steven Barlow <[email protected]> wrote: > However it is represented in serialised form, there should be a simple way of > reconstructing a valid deserialised cas. I'm assuming that there is some > hidden deeper structure on the cas object prototype that's getting lost. > Hopefully if I go digging, I may be able to isolate it, but it's a bit > frustrating: this should be pretty elementary behaviour I'd have thought. > > -- > You received this message because you are subscribed to the Google Groups > "Couchbase" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Couchbase" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
