Model published and/or updated *(similar to created)* field

[Zren]

With MongoDB. _id: { type: ObjectId } (which is the default id type) is made up of a timestamp of when the object was created (plus a few other things to make it unique across servers when you distribute the db). We can use it right now to fetch the creation date of scripts and other models.

It's currently possible to sort by creation date like so:
https://openuserjs.org/?orderBy=_id&orderDir=asc

To display it, we can use _id.getTimestamp(), but I think making a virtual (OWNER EDITED: static stored) property BaseSchema.created would be best.

[jerone]

I used a Mongoose plugin called mongoose-timestamp before, which adds createdAt and updatedAt date attributes that get auto-assigned to the most recent create/update timestamp.

Aldo this is not backwards compatible, it might be good practice to use it for every model.

Thinking about it, it may be backwards compatible for the script & discussion & group models with some routing to _id.getTimestamp() and existing updated. Other models are incompatible, but still useful.

[Zren]

Plugin looks nice, but we wouldn't want Script.updatedAt to reperesent Script.updated in it's current context as the Script model is updated every time someone installs a script. It should probably be called Script.sourceCodeUpdateAt. It'd be very useful for the Discussion/Comment models.

[Martii]

@Zren

Sorry didn't (recall) seeing this ticket and probably didn't understand it at the time it was posted...anywhooo...

Which other models did you want this added to?

I already added it to Script and User (models) in #485... we should continue to use _since as the virtual property name... and did you want to do anything different on the hard-coded dates? I may have to email sizzle to see if his commenting routine (Discussion and Comment) will be blocking since he is assigned to that as well as Vote ... and the virtual will currently need to check the existing creation date property first and return that instead.

[Zren]

Every single model can benifit from a createdAt and updatedAt column. You can't query over virtual functions (and we shouldn't really be querying on ObjectId since it includes other stuff). You can sort to find a new discussions, new votes, new groups, new ____.

did you want to do anything different on the hard-coded dates?

Eh? Are you talking about ObjectId.getTimestamp()? All I would use it for is populating the createdAt column if it was added.

[Martii]

You can't query over virtual functions

Please cite reference for this from mongoose package API docs. I'll try a query at some point in the near future to confirm. Thanks.

All I would use it for is populating the createdAt column if it was added.

Depending on the citation and testing... this is doable... although if "createAt" isn't necessary we should avoid hard-coding it into the schema.

[Zren]

Virtual functions aren't serialized into the db, nor are their calculated values, ergo you can't query over them.

http://mongoosejs.com/docs/guide.html#virtuals

[Martii]

http://mongoosejs.com/docs/guide.html#virtuals

"Only non-virtual properties work as part of queries and for field selection."

Thank you... elusive documentation and some contradicting elsewhere... also found setters there... good to know... will need to ponder on the relevance of sorting on creation date... not sure I see a need for that right off. (Anyone) Got any other use cases where we might be able to use this?

---

Paraphrased quote for today:

"Just because we can do something, doesn't necessarily mean that we should do something"

[Martii]

@jerone

I used a Mongoose plugin called mongoose-timestamp before...

I'm a little concerned with the issue on that repo at issue 26 ... would you validate that please? (no rush just when you have some time) I'd rather not add a dep (plugin) that might be considered abandonware... current last update is Feb 28, 2015... but he is active elsewhere. mongoose 3ish support is scheduled to be EOL'd in Sept 2015 and no backports of newer features are being made available at this time from what I've read.

[Martii]

@Zren
Another misc thought... this idea is good if we ever migrate the database from one db to another to maintain the creation date in case _id ever changes but the likelihood is up to sizzle. The _since virtuals seem to be working well and I still can't think of a reason why we would want to sort on creation date... but will ponder it some more.

[Martii]

@Zren
I've renamed this issue to be a little more encompassing. I can see a possible Moderator and above usage for checking for new User profile spammers. This is still being pondered but the scales are tipping a little bit. Tagged later label as there are much other higher priority issues to handle first.

The difference between published and created is simple... published means first appearance on OUJS (and could be a later revision like a book) whereas created could mean first instance ever of something, like a script, which is why I chose "Published" because it might be the first time on OUJS but the script could have been around for ages.

[Martii]

Still might do updated... this would detect existing accounts with those who updated it later... if implemented this will be hardcoded into the db as a static property and not a virtual for sure.

[Martii]

Status of this has changed due to additional testing. Not that we need extra columns (which are already pushing it on portables) but the precision of _since omits the milliseconds. There is also a concern that in a few dozen years, yes years, _since will have an issue similar to Y2K... guess the engineers didn't learn from this the first time i.e. clock wrap or just general failure of it.

I'll add a few created and updated fields to some of the models hopefully next week and begin a DB migration of the less-precise values.