Mongodb parent link tree get current location and full path
I am making a parent link tree with MongoDB and Mongoose. My schematic looks like this:
var NodesSchema = new Schema({
_id: {
type: ShortId,
len: 7
},
name: { // name of the file or folder
type: String,
required: true
},
isFile: { // is the node file or folder
type: Boolean,
required: true
},
location: { // location, null for root
type: ShortId,
default: null
},
data: { // optional if isFile is true
type: String
}
});
Please note that files / folders are renamed .
In my current setup, if I want to get files in a specific folder, I run the following query:
NodesModel.find({ location: 'LOCATION_ID' })
If I want to get one file / folder that I run:
NodesModel.findOne({ _id: 'ITEM_ID' })
and the location field looks like f8mNslZ1
, but if I want to get the name of the location folder, I need to do a second request.
Unfortunately, if I want to get the root path, I have to do a recursive query, which can be slow if I have 300 subfolders.
So I searched and figured out the following possible solution:
Should I change the location field from string to object and store information in it like this:
location: {
_id: 'LOCATION_ID',
name: 'LOCATION_NAME',
fullpath: '/FOLDERNAME1/FOLDERNAME2'
}
The problem with this solution is that the files / folders get renamed. When renaming, I have to update all children. Renaming happens much less frequently than indexing, however, but if the folder has 1000 items there will be a problem I guess.
My questions:
- Is my suggestion a location object instead of a string viable? What problems can arise?
- Are there any better ways to implement this?
- How can I improve my code?
source to share
Looking at the Node schema, if you change the property location
to an object you have 2 places where you put the Node name, so remember to update both name properties. Usually you want your database to be as DRY as possible, and in most cases, doing nested queries is fairly common. That being said, you know your database a lot more than I do, and if you see a significant performance lag with more queries, just be sure to update all the name properties.
In addition to this, if you have a location property that fullpath
is a string, and let's say that you are faced with a situation where you need to rename a folder, you will have to parse the entire string, breaking it up and comparing substrings with the new value for the new folder name. It can get tired.
A possible solution would be to store the full path as an array instead of a string, with the order being the next folder in the chain so you can quickly compare and update when needed.
source to share
Various ways of modeling tree structures are widely described in MongoDB docs .
The way you suggest is one of them.
Depending on how the re-renaming of the folder is expected (and / or any other hierarchy would be more complex than adding a new leaf node), you might instead store the "path" as an "ancestor array". Whichever way you denormalize or materialize the tree path in each folder, the tradeoff is that you will have slower and / or more complex updates for faster searches.
In your case, it seems to be optimized for reading and not for infrequent updates - in addition to being less rare, it seems like renaming can be done asynchronously if that just isn't possible when displaying parent folder names.
While DRY is a great programming principle, it hardly applies to non-relational databases, so unless you are using a strictly relational database and normal form, don't apply it to schema design, and in fact it would be particularly discouraged in MongoDB, since then you would be using the wrong tool for the job.
source to share