Develop Reference

update a Array without duplicate Map based on a parameter

I am currently using ArrayUnion to update an Array in a Document in Firebase. It Consists of a Map of the format {userid:XXXXXX,value:01234}. Now lets say I want to change this value, I was initially thinking of just using ArrayUnion and send an updated map, But how do I remove the pre-existing Map. (In Other Words No Too Map in the array can have the same ID).
Seems like a long shot, but I was also thinking maybe we can just use a Map which has a timestamp attribute to showing when it was added, and then on the client side ill perform the actions of removing those entries which are older.
Which of the options is better? and do you have any better solutions for the same problem?
(Note: Using Firebase v9 for Web)

The only way you can remove a map item from an array without reading the document first is if you know the entire contents of the map ahead of time. If you do, you can use arrayRemove, passing the entire map as an argument.
If you don't know the entire map contents, then your only option is to read the document into memory, modify the array the way you want in memory, then write the entire updated array field back to the document.
It is not possible to do anything with a map inside an array if you don't know its entire contents. If you only know one field, you can't update it and you can't use it in a query.
See:
Firestore Update single item in an array field
How to update an "array of objects" with Firestore?

How to store pointer to redis list element in hash object?

I know you are not able to nest redis data structures. Let me explain a little of what I have designed:
I have a sorted set, where each element in the set is the key name to a FIFO redis List.
I also need a direct lookup to each element, which I want to store in a Hash. In the hash, I would like to be able to point directly to an element in a redis List.
Is this possible? Any ideas how to tweak this?

Lists aren't suitable for random access (i.e. by index) - LRANGE is an expensive operation. Put differently, FIFO + random access it is not a job for a linked list.

Nodes Connecting to and from Multiple Other Nodes (in JavaScript or Ruby preferably)

I'm a newbie to data structures + algorithms, and while practicing interview questions, I came across the following:
say that we have individual nodes connecting to and from other (possibly multiple) nodes:
(1) Generate the data structure to store it all
(2) Generate the function to retrieve a list of all the nodes within "n"
hops from a particular node
I'm particularly not sure about what "data structure" to use. I thought okay, maybe we can create a node class, and have an array to reference all the nodes that a particular node points to. Then, in order to find the nodes that are within "n" hops from a particular node, we can iterate through that array of nodes, recursively call the function (passing n-1 this time) until we hit a base case of "1" hops. Could someone explain the error in my thinking and/or improve on it?
Appreciate any suggestions!

Can multiple "d3.js Dendrogram" nodes point to the same leaf node?

I've started a new JavaScript project based on the example at:
http://bl.ocks.org/mbostock/4063570
Everything with the d3 Dendrogram is great so far except that my data will probably always contain duplicate leaves (terminal nodes). In my data only the leaves could ever contain duplicate data. All internal nodes (between root and leaves) are strictly distinct well before d3 comes into play.
I could add something to the node(s) name (d.name) to make each node totally unique, but I'd rather 'reuse' leaf nodes and make all internal nodes point to and share a single leaf if possible.
Does anyone out there know how to do this?
Many thanks in advance!
Drew Barfield

The D3 data join expects that each DOM node will correspond to a different element in the data array. However, there's nothing stopping 2 elements in the data array from referring to the same underlying object.
It comes down to whether you are OK with the default join key (which is array index) or if you want to achieve a sense of "object permanence" on data update by mapping specific data elements to specific nodes. To have that happen you need to define a custom join key function, which by definition relies on some way to differentiate the data elements.
Personally, I think that if you're doing any amount of data updating involving enter/exit/update, life will be much easier if each data element is unique and has some kind of "id" or "key" property that you can use to identify it. Reusing data elements will likely be more headache than it's worth.
You didn't actually mention what you are trying to achieve by sharing data? Is it just a memory saving optimization or is there another reason? If it's just memory, I wouldn't bother.

Look up elements in a generic tree

I have a json nested object, similar to this.
In my case, I have a unique id field of type int(say instead name above). This is not a binary tree, but more depict parent-child relationship. I wanted a way to easy lookup the child tree (children) rooted at say id = 121. In a brute force way, I may compare all nodes till I find one, and return the children. But I was think of keeping a map of {id, node}. For example {"121" : root[1][10]..[1]}. This may be super wastefulness of memory (unless use a pointer to the array).Note sure any better way.
I have control over what to send from server, so may augment above data structure. but need a quick way to get child tree based on node id in the client side.
EDIT:
I am considering keeping another data structure, map of {id, []ids}, where ids is the ordered path from root. Any better way?

Objects in javascript are true pointer-based objects, meaning that you can keep multiple references to them without using much more memory. Why not do a single traversal to assign the sub-objects to a new id-based parent object? Unless your hierarchical object is simply enormous, this should be very fast.
In light of best practice and what would happen if the application you're building were to scale to millions of users, you might rethink whether you really want the server to do more work. The client's computer is sitting there, ready to provide you with remote computing power for FREE. Why move the work load to the server causing it to process fewer client requests per second? That may not be a direction you want to go.
Here is a fiddle demonstrating this index-building technique. You run through it once, and use the index over and over as you please. It only takes 4 or 5 ms to build said index. There is no performance problem!
One more note: if you are concerned with bandwith, one simple way to help with that is trim down your JSON. Don't put quotes around object key names, use one-letter key names, and don't use whitespace and line breaks. That will get you a very large improvement. Performing this change to your example JSON, it goes from 11,792 characters to 5,770, only 49% of the original size!
One minor note is that object keys in javascript are always Strings. The numeric ids I added to your example JSON are coerced to strings when used as a key name. This should be no impediment to usage, but it is a subtle difference that you may want to be aware of.

I don't assume that the ids are somehow ordered, but still it might help to prune at least parts of the tree if you add to each node the information about the minimum and maximum id value of its children (and sub... children).
This can be quite easily be achieved at server side and when searching the tree you can check if the id you're looking for is within the id-range of a node, before stepping inside and searching all children.