All objects should have some inherent properties

[silverbucket]

There should be some prototype properties on all object, things like date related fields. accessed, modified, created.

I remember talking about other good candidates for inherent fields, but can't remember at the moment.

[webr3]

Nick Jennings wrote:

There should be some prototype properties on all object, things like date related fields. accessed, modified, created.

I remember talking about other good candidates for inherent fields, but can't remember at the moment.

Identifier(s) and Type(s) are about the only two generic ones in addition to the audit/provenance ones you mentioned.

[nilclass]

I don't like doing this by default. We can provide some useful base-schemas though, that other schemas can be built on. json-schema defines the extends property for this.

Maybe something like this (in remoteStorage.js itself):

declareType('base-object', {
  "description": "...",
  "type": "object",
  "properties": {
    "created": { ... },
    "modified": { ... }
  }
});

And then when you declare a type:

declareType('my-type', {
  "description": "...",
  "type": "object",
  "extends": "base-object",
  "properties": { ... }
});

That way it is not enforced, but still possible to have defaults. The timestamp properties would also need some kind of schema-specific hooks, that will set the timestamps before validating the object. I'm not sure yet how that will look, open for suggestions.

One more thing: the "accessed" property seems a bit over the top to me, because then just looking at something in one app would cause a PUT and may in turn cause an edit conflict in another app, because the remote timestamp (the one used to figure out if the object has changed on the remote server since it was last retrieved) would have updated, even though the object's primary data didn't really change.

By the way, if you want to figure out when an object really changed (i.e. when it was last updated locally or last pushed to remote), you can use getObject on the parent directory:

client.getObject('/videos/')
// -> 
{
  "youtube_xnSc_OWpCuY": 1349272766285
}

This is possible, because directory nodes are stored in the same format as they are retrieved from the server, see 2012.04#GET.

[silverbucket]

On Mon, Oct 22, 2012 at 2:00 PM, Niklas Cathor notifications@github.comwrote:

I don't like doing this by default. We can provide some useful base-schemas though, that other schemas can be built on. json-schema defines the extendshttp://tools.ietf.org/html/draft-zyp-json-schema-03#section-5.26property for this.

Maybe something like this (in remoteStorage.js itself):

declareType('base-object', { "description": "...", "type": "object", "properties": { "created": { ... }, "modified": { ... } }});

And then when you declare a type:

declareType('my-type', { "description": "...", "type": "object", "extends": "base-object", "properties": { ... }});

That way it is not enforced, but still possible to have defaults. The timestamp properties would also need some kind of schema-specific hooks, that will set the timestamps before validating the object. I'm not sure yet how that will look, open for suggestions.

Then you have the issue where a group of documents may or may not have date-related properties... Why wouldn't we ever want these base-properties to exist though? I'm not sure I understand the downsides.

And just to clarify, these date related schema definitions would indicate to the remoteStorage.js lib that it handles the updating of the fields itself - the module nor the app have to worry about this, they just access the field when they need to read from it, right?

One more thing: the "accessed" property seems a bit over the top to me, because then just looking at something in one app would cause a PUT and may in turn cause an edit conflict in another app, because the remote timestamp (the one used to figure out if the object has changed on the remote server since it was last retrieved) would have updated, even though the object's primary data didn't really change.

Sure, I was just throwing out all the possibilities I could think of off the top of my head. I agree accessed is probably something we shouldn't worry about.

By the way, if you want to figure out when an object really changed (i.e. when it was last updated locally or last pushed to remote), you can use getObject on the parent directory:

client.getObject('/videos/')// -> { "youtube_xnSc_OWpCuY": 1349272766285}

This is possible, because directory nodes are stored in the same format as they are retrieved from the server, see 2012.04#GEThttp://www.w3.org/community/unhosted/wiki/RemoteStorage-2012.04#GET .

— Reply to this email directly or view it on GitHubhttps://github.com/RemoteStorage/remoteStorage.js/issues/122#issuecomment-9661081.

[nilclass]

Then you have the issue where a group of documents may or may not have date-related properties... Why wouldn't we ever want these base-properties to exist though? I'm not sure I understand the downsides.

• It wouldn't work for Arrays.
• It adds extra complexity when storing data, even if the feature is not used.

Common MVC frameworks that have this feature also make it optional, like rails' table.timestamps and django's DateField.auto_now, so I think many people are already familiar with the concept.

And just to clarify, these date related schema definitions would indicate to the remoteStorage.js lib that it handles the updating of the fields itself - the module nor the app have to worry about this, they just access the field when they need to read from it, right?

What I meant by schema-specific hooks is, that there should be a way to say "when an object with this type/schema is validated, run this function first" (like a filter). That would be a general thing, that all types then can have. If a type were implemented within remoteStorage.js (such as the "base-object" example above), the filters it needs would naturally be part of remoteStorage.js as well. Another case where this feature may be useful is the "id" field, as mentioned in #111.

[silverbucket]

On Mon, Oct 22, 2012 at 3:34 PM, Niklas Cathor notifications@github.com wrote:

Then you have the issue where a group of documents may or may not have date-related properties... Why wouldn't we ever want these base-properties to exist though? I'm not sure I understand the downsides.

It wouldn't work for Arrays.

OK, so Arrays would be exceptions.

It adds extra complexity when storing data, even if the feature is not used.

Common MVC frameworks that have this feature also make it optional, like rails' table.timestamps and django's DateField.auto_now, so I think many people are already familiar with the concept.

I don't think an MVC framework is a good analogy, the data sets defined are agreed upon by everything using it, obviously, since it's all going to be within the realm of that code-base.

A much better analogy, IMO, is a filesystem. Any files created on the filesystem has timestamp properties, and those that don't are the exceptions (as the arrays would be in our case). When writing code to interface with these files you have common expected characteristics of each file and can write your code assuming that's the case.

As with a filesystem, If someone needs to optimize for performance reasons, it should be the exception that explicitly says "don't handle date properties".

And just to clarify, these date related schema definitions would indicate to the remoteStorage.js lib that it handles the updating of the fields itself - the module nor the app have to worry about this, they just access the field when they need to read from it, right?

What I meant by schema-specific hooks is, that there should be a way to say "when an object with this type/schema is validated, run this function first" (like a filter). That would be a general thing, that all types then can have. If a type were implemented within remoteStorage.js (such as the "base-object" example above), the filters it needs would naturally be part of remoteStorage.js as well.

That's a good idea.

Another case where this feature may be useful is the "id" field, as mentioned in #111.

Agreed.

[raucao]

Also see http://community.remotestorage.io/t/core-extensions-available-in-modules/18