parse-server
parse-server copied to clipboard
parse-community
Allow to set `createdAt` and `updatedAt` during data import(s)
New Feature / Enhancement Checklist
- [x] I am not disclosing a vulnerability.
- [x] I am not just asking a question.
- [x] I have searched through existing issues.
Current Limitation
I'm sure it was discussed somewhere, but i could not find anything.
Currently when you import data from a different source, there is no way to set createdAt and updatedAt fields to the existing value of the imported source.
Feature / Enhancement Description
I'm not sure if theses fields have an impact of core parse functionalities, but here is a few suggestions:
- When creating a new object, If
createdAtorupdatedAtfields exists and have a valid value, use theses values. Leave as-is when updating an object - Add a
flag/optioninParse.Object.save()to indicate you want to preserve theses fields.
Example Use Case
In our app we allow users to import transactions from various sources. Currently we need to save the transaction date into a separate field since createdAt is not usable.
In a few other projects, we are syncing data from a 3rd party into Parse DB, and since we cannot use createdAt to store the event creation date, we need to store this in a separate field. This cause confusion, since its not clear why you have two fields to store the parse object creation and event creation
Alternatives / Workarounds
- Add user's
createdAt/updatedAtvalues into new fieldsuserCreatedAtanduserUpdatedAt - Add all objects
- Use MongoDB adapter to update
createdAt = userCreatedAt
3rd Party References
Thanks for suggesting. This seems to be a valid use case.
In general, even though the createdAt and updatedAt fields are Parse Object meta fields, they are often used implicitly as data fields. This is a fair usage because:
- Semantically,
createdAt/updatedAtare obvious and simple field names for when an object has been created / updated. - Not having to add additional date fields saves data traffic and DB storage.
If being used as a data field, it should be possible to set it on object creation, but also to edit when updating an existing object.
There should be no substantial implication in the server or SDKs because being date fields, it would be unreliable to draw any conclusion about the object state. If there was indeed object state logic depending on these fields, removing these dependencies would be an improvement as a side effect of this PR.
Do you want to look into this and open a PR?
(Note: I removed the link to your product as advertising; it is not relevant to this issue.)
I'll try to have a look, but I want to complete.the others PRs before.
It might take some time but I'll try a few things out.
There should be no substantial implication in the server or SDKs because being date fields, it would be unreliable to draw any conclusion about the object state. If there was indeed object state logic depending on these fields, removing these dependencies would be an improvement as a side effect of this PR.
Currently, the allowCustomObjectId setting uses createdAt in the JS and Swift SDK do determine if an object should be saved/updated (.POST/.PUT) to the server.
JS: https://github.com/parse-community/Parse-SDK-JS/blob/ffc523f9cd0fa2dd3fcc9754d5f15c3c1c78314f/src/ParseObject.js#L326-L348
Swift:
- Determining save: https://github.com/parse-community/Parse-Swift/blob/a8b3d00b848f3351d2c61a569d4ad4a3c96890d2/Sources/ParseSwift/Protocols/Objectable.swift#L79-L85
- Using the saved state: https://github.com/parse-community/Parse-Swift/blob/0ea2385520858b824582a336c50387fe28b04bab/Sources/ParseSwift/API/API%2BCommands.swift#L334-L363
The potential of this PR seems like there will need to more items resolved before it can be implemented. Currently, the Server can accept ParseObjects with/without custom objectId’s from clients when allowCustomObjectId = true. It doesn’t seem like this would be the case if this PR is implemented. The server PR that enabled customObjectId’s is #6177
If this does end up being implemented, I recommend it has an on/off feature and it should be off by default.
Currently, the allowCustomObjectId setting uses createdAt in the JS and Swift SDK do determine if an object should be saved/updated (.POST/.PUT) to the server.
It only determines whether createdAt exists, not its value. If we establish the rule that a saved object always must have a createdAt / updatedAt, that shouldn't interfere (much).
The approaches you referenced seem a bit flawed anyway. Various ways to determine whether an object has been saved or not, depending on whether custom obj id is set, looks too complex with the potential for ambiguity, as we see now with this proposed change.
@cbaker6 my idea for a first step would be ONLY for freshly created objects.
IFF you save a new object, and the object contains updatedAt/createdAt theses value would be used instead of the generated one on the server.
** Actually, I really only care about createdAt. I'm not sure if overwriting updatedAt make sense anyway. **
So I think this PR scope will be limited to :
- freshly created objects
- that contains a valid
createdAt - provided date
<now()
It will also reduce the required changes and avoid nasty side effects.
Would that solve the problem for the API clients ?
The approaches you referenced seem a bit flawed anyway. Various ways to determine whether an object has been saved or not, depending on whether custom obj id is set, looks too complex with the potential for ambiguity, as we see now with this proposed change.
All of the SDKs use objectId to determine if an object has been saved already. Using createdAt to determine if the object has actually been saved to the server based on createdAt and updatedAt being server business logic sounds like a reasonable iteration to me. Then again, I was not part of those discussions. If there needs to be a different way to enable the PR in this thread? What would it be?
Would that solve the problem for the API clients ?
I’m not sure... I made my comment just to mention that createdAt is currently used to determine state on the client side which effects how it sends data to the server.
This feature would be appreciated. Currently I connect to mongodb manually from my seed scripts to populate createdAt and updatedAt. curious to know, would this be a bad practice? Meaning is there any side effect in terms of how parse stores these fields internally?
