cross-namespace kind metadata

[pcostell]

When a user registers a kind, they must also specify a namespace. My understanding of namespace usage is that most people use it to separate customer/user data. However in this case, you'd want to have dynamic namespaces for each customer, but the information about your kinds would want shared across all namespaces, since you are running the same application for each customer.

In this case, you would want to specify the namespace of a specific key/entity when you do the get/put, since this is the point where you know which customers data you are working with.

[rakyll]

We should allow registration of kinds globally by default, and allow them to optionally override type schema for a given set of namespaces.

[ryanseys]

Sorry, I don't understand this issue. Could you provide an example? Perhaps with some (psuedo)code that explains essentially what is happening now vs. what would be better to happen?

[pcostell]

From the example:

registerKind('namespace', 'Author', {
   name: { kind: String, indexed: false },
   tags: { kind: String, multi: true }, // an array of string elements.
   favArticles: { kind: KEY, multi: true },
     contact: {
       kind: {
         telephone: { kind: String },
         email: { kind: String }
      }
   }
});

Preferred method:

registerKind('Author', {
   name: { kind: String, indexed: false },
   tags: { kind: String, multi: true }, // an array of string elements.
   favArticles: { kind: KEY, multi: true },
     contact: {
       kind: {
         telephone: { kind: String },
         email: { kind: String }
      }
   }
});

[pcostell]

However, I'm not convinced that the gcloud API should expose this. It seems we should focus on getting gcloud to support both ndb and the simple key-value store. For users that want model definitions we should just recommend ndb.

[jgeewax]

We don't have this method -- moving this to Datastore Future (if at all).

[pcostell]

Oops sorry for some reason I thought we were talking python...

registerKind does look like is still exists in lib/datastore/entity.js. In this case the ndb argument does not apply, but it may be worthwhile to separate the ORM code into a separate module/directory.