Start a new topic

Metadata Time Missing

On iOS, some of the records in the data store are being loaded in with the metadata times both set to nil. I can't find any rhyme or reason to it. Some of them were created in the console interface, some were created using the kinveyEntity() module in business logic and then populated using a uri request. Both have worked and both have not worked. All show their dates in the data store interface (though some created with a uri request have strangely rounded-off times)



Has anyone else run into mysterious fantom creation and last modified dates?

What does the entity look like when it does not resolve the metadata time? Can you GET it using the API console and paste the output here?
Here is the response from the API Console. It is a sent message which resolves a _message and its messageType. The only difference I can see is the order which the times are listed. The parent object is the one which is created with nil times on iOS.



HTTP/1.1 200

Content-Type: application/json

X-Kinvey-API-Version: 3

X-Kinvey-Request-Id: 5f6fcfcdc1ff480f826f93aa5ad1a1f3

X-Powered-By: Express



[

{

"_message": {

"_collection": "Messages",

"_id": "532affdef811291203085488",

"_type": "KinveyRef",

"_obj": {

"_id": "532affdef811291203085488",

"subject": "Introductory Email",

"message_body": "message body",

"push_alert": "Welcome guest.",

"important": false,

"from": "Name",

"_message_type": {

"_type": "KinveyRef",

"_id": "531f1e1f403f26fb02006059",

"_collection": "MessageType",

"_obj": {

"_id": "531f1e1f403f26fb02006059",

"name": "Message",

"color": "green",

"_acl": {

"creator": "kid_PeHNrm7vLq"

},

"_kmd": {

"lmt": "2014-03-11T14:43:40.488Z",

"ect": "2014-03-11T14:30:55.452Z"

}

}

},

"_acl": {

"creator": "kid_PeHNrm7vLq"

},

"_kmd": {

"lmt": "2014-03-23T02:16:16.497Z",

"ect": "2014-03-20T14:49:02.057Z"

}

}

},

"to": {

"_collection": "user",

"_id": "53312088f8112912030af9d3",

"_type": "KinveyRef"

},

"_acl": {

"creator": "kid_PeHNrm7vLq"

},

"_kmd": {

"ect": "2014-03-25T06:22:00+00:00",

"lmt": "2014-03-25T06:22:00+00:00"

},

"_id": "53312088864c85df6ea17b53",

"skipNotification": "TRUE"

}

]
How is your object saved? "2014-03-25T06:22:00+00:00" is not a valid date string (for our library). It expects it in the form "2014-03-25T06:22:00.000Z"
We're using kinveyEntity() to construct it in a collection cook like so.



function sm() {

this._message = messageRef;

this.to = userRef;

}

var sentMessage = modules.utils.kinveyEntity(new sm());



Then we're setting up the uri and headers and using a request to create the object



var req = modules.request;

req.post({uri: uri, headers: headers, json: sentMessage}, function(error, resp, body){});
More info on the headers. We have a similar script that uses the request's authorization and works correctly

var headers = { 'Authorization': request.headers.authorization };



On this one which causes incorrect metadata, we're creating a new sent message when the user is created. The request's authorization is not sufficient when the user is being created since it is not being called from an active user, so we are manually creating the auth headers for the master user to do the creation. The record is being created, but with this one issue of incorrectly formatted metadata times.



Right now, we are using base64 to encode the app key and master secret to generate the headers:

var headers = { 'Authorization': 'Basic ' + base64_encode(context.getAppKey() + ':' + context.getMasterSecret())};



I can't think of why that would cause improperly formatted times though.
I think a teammate figured out what was causing it. When we stopped using the kinveyEntity() module to generate the record and just sent it to be created in a raw state it was initialized properly.



I think we had a similar problem when we were trying to directly create a record within a collection hook using the collectionAccess module, but it was a while ago so I can't be sure.
There is a bug in kinveyEntity(), we're working on a fix.
OK, I thought that might be the case, good to know.
Login or Signup to post a comment