Log file Viewer

[13:37:27] <hoijui> is it possible to have mongodb maintain a git repo of all the data, and make a git commit on every edit to the data?

[13:37:50] <hoijui> (and a push, optionally

[13:43:34] <GothAlice> That request is a) non-sensical, b) a terribly bad idea as a mis-use of Git, which is meant to handle, and best processes line-oriented text data.

[13:44:07] <GothAlice> "git diff" a BSON record, any change will mark the whole thing as changed. (Game over for SCM systems.)

[13:44:59] <GothAlice> Instead, consider the reverse. Store versioned information within MongoDB itself.

[13:46:15] <GothAlice> hoijui: ^

[13:47:15] <hoijui> GothAlice, I though one could use JSON, XML or BSON as backend?

[13:47:31] <GothAlice> Find back the bookmark that told you that, and lose it.

[13:47:32] <hoijui> and I did not understand .. how to stre versioned info in the DB?

[13:47:41] <hoijui> ok :D

[13:48:01] <GothAlice> http://bsonspec.org ← storage format, wire driver format, format.

[13:48:39] <hoijui> *stre -> store

[13:49:18] <hoijui> we have a tiny DB, with just one user entering data, once every few days at most

[13:49:37] <hoijui> we want the data in a textual format in git

[13:49:46] <hoijui> guess mongodb is not for us then

[13:50:01] <GothAlice> hoijui: https://duckduckgo.com/?q=mongodb+versioned+records — first link, e.g. https://tools.ietf.org/html/rfc6902

[13:50:59] <GothAlice> Then use git and on-disk file structure as your database. That's rather unfortunate (goodbye ability to "query" the data), but is the easy path (picking only {fast} of {good, fast, cheap}) to getting what you seem to want.

[13:52:10] <GothAlice> It's not {cheap} as it will take a fair amount of effort to learn how to abuse Git in this way and keep it manageable, and there will be few resources available to assist you. (Welcome to research and development! ;)

[13:52:37] <hoijui> mmmm

[14:10:40] <hoijui> GothAlice, https://www.mongodb.com/what-is-mongodb it says: "MongoDB stores data in flexible, JSON-like documents, ..." and then there is an image of a JSON document

[14:11:10] <hoijui> one shoudl not be surprised if newbs think data gets stored in plain text

[14:12:13] <GothAlice> JSON-like in terms of type representation, extended. http://bsonspec.org. Binary. Not suitable for text processing.

[14:12:33] <GothAlice> This is the problem with only reading the TL;DR/

[15:49:03] <AJTJ> hello, how do I trace collection.count errors?

[15:49:23] <AJTJ> or rather, collection.count deprecation warnings?

[18:34:38] <GothAlice> AJTJ: Google "mongodb collection.count" without quotes, click the first link to: https://docs.mongodb.com/manual/reference/method/db.collection.count/ — heed the deprecation warning and change your code to use one of the specific methods: countDocuments or estimatedDocumentCount.

[18:37:37] <GothAlice> (The "Important" note below the mention of those methods explains why there's a distinction. The latter relies on collection metadata, which may not be 100% accurate for reasons listed in that note.)

[18:40:07] <GothAlice> (But will be fast.)

[19:00:51] <AJTJ> GothAlice: cool, I use mongoose, and I'm wondering if this is different from model.count

[19:01:00] <AJTJ> which is a mongoose thing

[19:01:15] <AJTJ> same for collection.update vs model.update

[19:04:59] <GothAlice> All of those will boil down to the same command invocations over the wire as the mongo shell. Though, another warning sign: update. update_one, update_many. These are now split operations.

[19:07:20] <GothAlice> If the version of mongoose you're using doesn't have/offer the modern APIs, upgrade, or if no update is available, you're probably going to want to find a new abstraction layer, or don't use abstraction layers. (I've been leaning more towards not using "active record" "schema modelling" layers, and using the bare native driver more.)

[19:58:29] <AJTJ> GothAlice: thx

[19:58:37] <AJTJ> GothAlice: I'm trying to create this:

[19:58:41] <AJTJ> "updatedAt": {

[19:58:41] <AJTJ> "$date": "2019-11-08T19:55:37.918Z"

[19:58:41] <AJTJ> },

[19:59:16] <AJTJ> but, Date.now() only creates UTC milliseconds

[21:28:38] <AJTJ> figured it out, I had to declare this key/value pair in my model type: Date leadUpdated: { type: Date, default: Date.now },

[21:28:42] <AJTJ> leadUpdated: { type: Date, default: Date.now },