Changed DB to store node positions as Ordinals.

sync/internal_api/public/base/ordinal.h

Index: sync/internal_api/public/base/ordinal.h
diff --git a/sync/internal_api/public/base/ordinal.h b/sync/internal_api/public/base/ordinal.h
index 91897599e782efda44c6854ee11bfbe31dabf3da..aa6ffa91fcf92b96015fc369e8a45bbef56dcb0b 100644
--- a/sync/internal_api/public/base/ordinal.h
+++ b/sync/internal_api/public/base/ordinal.h
@@ -78,7 +78,7 @@ class Ordinal {
   // may be valid or invalid.
   explicit Ordinal(const std::string& bytes);
 
-  // Creates an invalid Ordinal.
+  // Creates a valid initial Ordinal.

[akalin, 2012/10/05 00:57:59]

hmm why is this necessary?  Why not CreateInitialOrdinal()?

[vishwath, 2012/10/05 18:34:49]

There are multiple places where new entry kernels are created and then inserted
into directory indices. This creates a problem when the SERVER_ORDINAL field is
later queried since it contains an invalid ordinal. I could just add a call to
CreateInitialOrdinal() in the entry kernel constructor instead. Do we need the
default constructor to create invalid ordinals though? 

On 2012/10/05 00:57:59, akalin wrote:

[rlarocque, 2012/10/05 19:02:55]

I think the trend is to initialize those values in the MutableEntry's
constructor or init function.

The default invalid ordinals are a safety to ensure we don't accidentally use
ordinals that we intended to initialize, but didn't.

[vishwath, 2012/10/05 21:05:48]

Entrykernels are also created in directory_backing_store for instance (in the
UnpackEntry() method). I could ensure that all instantiations of an entrykernel
are followed by setting the server_ordinal_field to a valid value. Does that
seem like a better option?

On 2012/10/05 19:02:55, rlarocque wrote:

[akalin, 2012/10/05 21:20:15]

Yeah.  Ideally, EntryKernels would have to be constructed with a valid ordinal.

[rlarocque, 2012/10/05 21:29:34]

I think I agree, but I just want to clarify.

EntryKernels have a lot more in common with C structs than C++ classes.  It
currently has a single constructor that takes no parameters.  If we require that
the caller provide a valid server_ordinal, it would be the first field in the
EntryKernel to impose such a requirement.

I think it makes sense to require the context that creates the EntryKernel to
properly initialize its fields.  The Ordinal class has plenty of DCHECKs that
would help ensure that no one accesses the invalid, default-constructed
ordinals.  Is that what you're proposing?

If the zero-argument constructor initialized the ordinal to a valid value
automatically, then we would no longer be able to distinguish between a default
and unintentionally never set value.

   Ordinal();
 
   // Creates a valid initial Ordinal. This is called to create the first
@@ -232,7 +232,11 @@ Ordinal<Traits>::Ordinal(const std::string& bytes)
       is_valid_(IsValidOrdinalBytes(bytes_)) {}
 
 template <typename Traits>
-Ordinal<Traits>::Ordinal() : is_valid_(false) {}
+Ordinal<Traits>::Ordinal()
+    : bytes_(Traits::kMinLength, kZeroDigit),
+      is_valid_(true){
+  bytes_[0] = kMidDigit;
+}
 
 template <typename Traits>
 Ordinal<Traits> Ordinal<Traits>::CreateInitialOrdinal() {