You have to do it step by step if you don't want a TypeError
because if one of the members is null
or undefined
, and you try to access a member, an exception will be thrown.
You can either simply catch
the exception, or make a function to test the existence of multiple levels, something like this:
function checkNested(obj /*, level1, level2, ... levelN*/) {
var args = Array.prototype.slice.call(arguments, 1);
for (var i = 0; i < args.length; i++) {
if (!obj || !obj.hasOwnProperty(args[i])) {
return false;
}
obj = obj[args[i]];
}
return true;
}
var test = {level1:{level2:{level3:'level3'}} };
checkNested(test, 'level1', 'level2', 'level3'); // true
checkNested(test, 'level1', 'level2', 'foo'); // false
ES6 UPDATE:
Here is a shorter version of the original function, using ES6 features and recursion (it's also in proper tail call form):
function checkNested(obj, level, ...rest) {
if (obj === undefined) return false
if (rest.length == 0 && obj.hasOwnProperty(level)) return true
return checkNested(obj[level], ...rest)
}
However, if you want to get the value of a nested property and not only check its existence, here is a simple one-line function:
function getNested(obj, ...args) {
return args.reduce((obj, level) => obj && obj[level], obj)
}
const test = { level1:{ level2:{ level3:'level3'} } };
console.log(getNested(test, 'level1', 'level2', 'level3')); // 'level3'
console.log(getNested(test, 'level1', 'level2', 'level3', 'length')); // 6
console.log(getNested(test, 'level1', 'level2', 'foo')); // undefined
console.log(getNested(test, 'a', 'b')); // undefined
The above function allows you to get the value of nested properties, otherwise will return undefined
.
UPDATE 2019-10-17:
The optional chaining proposal reached Stage 3 on the ECMAScript committee process, this will allow you to safely access deeply nested properties, by using the token ?.
, the new optional chaining operator:
const value = obj?.level1?.level2?.level3
If any of the levels accessed is null
or undefined
the expression will resolve to undefined
by itself.
The proposal also allows you to handle method calls safely:
obj?.level1?.method();
The above expression will produce undefined
if obj
, obj.level1
, or obj.level1.method
are null
or undefined
, otherwise it will call the function.
You can start playing with this feature with Babel using the optional chaining plugin.
Since Babel 7.8.0, ES2020 is supported by default
Check this example on the Babel REPL.
🎉🎉UPDATE: December 2019 🎉🎉
The optional chaining proposal finally reached Stage 4 in the December 2019 meeting of the TC39 committee. This means this feature will be part of the ECMAScript 2020 Standard.
My favorite answer is as what the first sentence in this thread suggested. Use an Adjacency List to maintain the hierarchy and use Nested Sets to query the hierarchy.
The problem up until now has been that the coversion method from an Adjacecy List to Nested Sets has been frightfully slow because most people use the extreme RBAR method known as a "Push Stack" to do the conversion and has been considered to be way to expensive to reach the Nirvana of the simplicity of maintenance by the Adjacency List and the awesome performance of Nested Sets. As a result, most people end up having to settle for one or the other especially if there are more than, say, a lousy 100,000 nodes or so. Using the push stack method can take a whole day to do the conversion on what MLM'ers would consider to be a small million node hierarchy.
I thought I'd give Celko a bit of competition by coming up with a method to convert an Adjacency List to Nested sets at speeds that just seem impossible. Here's the performance of the push stack method on my i5 laptop.
Duration for 1,000 Nodes = 00:00:00:870
Duration for 10,000 Nodes = 00:01:01:783 (70 times slower instead of just 10)
Duration for 100,000 Nodes = 00:49:59:730 (3,446 times slower instead of just 100)
Duration for 1,000,000 Nodes = 'Didn't even try this'
And here's the duration for the new method (with the push stack method in parenthesis).
Duration for 1,000 Nodes = 00:00:00:053 (compared to 00:00:00:870)
Duration for 10,000 Nodes = 00:00:00:323 (compared to 00:01:01:783)
Duration for 100,000 Nodes = 00:00:03:867 (compared to 00:49:59:730)
Duration for 1,000,000 Nodes = 00:00:54:283 (compared to something like 2 days!!!)
Yes, that's correct. 1 million nodes converted in less than a minute and 100,000 nodes in under 4 seconds.
You can read about the new method and get a copy of the code at the following URL.
http://www.sqlservercentral.com/articles/Hierarchy/94040/
I also developed a "pre-aggregated" hierarchy using similar methods. MLM'ers and people making bills of materials will be particularly interested in this article.
http://www.sqlservercentral.com/articles/T-SQL/94570/
If you do stop by to take a look at either article, jump into the "Join the discussion" link and let me know what you think.
Best Answer
Can you output a tree structure from a view? No. CouchDB view queries return a list of values, there is no way to have them output anything other than a list. So, you have to deal with your map returning the list of all descendants of a given bucket.
You can, however, plug a
_list
post-processing function after the view itself, to turn that list back into a nested structure. This is possible if your values know the_id
of their parent — the algorithm is fairly straightforward, just ask another question if it gives you trouble.Can you grab a document by its id in the map function? No. There's no way to grab a document by its identifier from within CouchDB. The request must come from the application, either in the form of a standard
GET
on the document identifier, or by addinginclude_docs=true
to a view request.The technical reason for this is pretty simple: CouchDB only runs the map function when the document changes. If document
A
was allowed to fetch documentB
, then the emitted data would become invalid whenB
changes.Can you output all descendants without storing the list of parents of every node? No. CouchDB map functions emit a set of key-value-id pairs for every document in the database, so the correspondence between the key and the id must be determined based on a single document.
If you have a four-level tree structure
A -> B -> C -> D
but only let a node know about its parent and children, then none of the nodes above know thatD
is a descendant ofA
, so you will not be able to emit the id ofD
with a key based onA
and thus it will not be visible in the output.So, you have three choices:
B
knows thatC
is a descendant ofA
), and grab additional levels by running the query again.