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.

[jgeewax]

Kicking this over to @stephenplusplus to comment... Maybe we should get rid of this registerKind method? (see https://github.com/GoogleCloudPlatform/gcloud-node/blob/cdd41388c4f9b624f663bffb85f88bbae63780a8/lib/datastore/entity.js#L620)

[stephenplusplus]

That apparently has been lingering around in the code since last May waiting for an implementation. I'll open a PR to kill it.

[ryanseys]

Are we killing this issue or can we better define what the requirements are for it?

[jgeewax]

I would agree with @pcostell that if we're going to introduce schema-like things for some sort of ORM, it should live in it's own repository (though possibly magically packaged up so that distribution is all one npm install).

I think it's certainly outside the scope of "Datastore stable" which is our focus right now.

[stephenplusplus]

Working on this over in: https://github.com/stephenplusplus/gcloud-datastore-schema -- please re-open this or post an issue over there if it's not the right approach (it's a WIP).