feat: add merge feature

[louib]

This is a very early version of a merge feature. KeePassXC defines 5 merge modes, but I don't think we need all the 5 modes in the first version of this feature, if ever

TODOs

• handle location update
• handle deleted objects
• handle group updates
• move the feature behind a feature flags

[phoerious]

I haven't checked the correctness of what this is doing yet, but I think the code can be streamlined quite a lot.

[phoerious]

You are using unwrap() so often, this method should return a Result type instead.

[phoerious]

See comment above, then

Suggested change

	let mut source_history = other.history.clone().unwrap_or(History::default());
	let mut source_history = other.history.clone().ok_or("No history")?;

[phoerious]

Suggested change

	let mut new_history = self.history.clone().unwrap_or(History::default()).clone();
	let mut new_history = self.history.clone().unwrap_or_else(|| History::default()).clone();

[phoerious]

See above.

[phoerious]

This should probably be Option<bool>, then you can save a lot of boilerplate in the function body.

[phoerious]

Suggested change

	for node in &mut self.children {
	if let Node::Entry(e) = node {
	response.push(e)
	}
	}
	self.children.iter_mut().flat_map(|node| {
	match node {
	Node::Entry(e) => Some(e),
	_ => None
	}
	}).collect()

[phoerious]

Suggested change

	for node in &mut self.children {
	if let Node::Group(g) = node {
	response.push(g);
	}
	}
	self.children.iter_mut().flat_map(|node| {
	match node {
	Node::Group(g) => Some(g),
	_ => None
	}
	}).collect()

[phoerious]

You should probably implement a recursive iterator, so you can do this:

Suggested change

	for node in &self.children {
	match node {
	Node::Group(g) => {
	if let Some(e) = g.find_entry_by_uuid(id) {
	return Some(e);
	}
	}
	Node::Entry(e) => {
	if e.uuid == id {
	return Some(e);
	}
	}
	}
	}
	None
	self.iter_recursive()
	.flat_map(|c| {
	match c {
	Node::Entry(e) => Some(e),
	_ => None
	}
	})
	.find(|e| e.uuid == id)

[phoerious]

Suggested change

	for node in &self.children {
	self.children.iter_mut().for_each(|node| {

[louib]

Not sure what's the advantage of this proposition. We don't need a mutable reference to the node, and the proposed syntax is more verbose.

[phoerious]

The mut was a bit of an oversight. iter() should be sufficient. Overall, the iterator syntax should be preferred. It's cleaner and often faster than the for-loop.

[louib]

@phoerious

often faster than the for-loop.

Do you have a source for that? I would like to know why that's the case.

It's cleaner

I personally prefer the for syntax, especially in Rust. Notice the absence of parentheses on the line where the for is declared ✨

[phoerious]

Do you have a source for that? I would like to know why that's the case.

The iterators are usually as fast, sometimes faster. The difference isn't huge, but I guess it comes mostly from Rust's automatic SIMD vectorization. The same happens for for loops, but I guess they are sometimes not as easy to optimize.

I personally prefer the for syntax, especially in Rust. Notice the absence of parentheses on the line where the for is declared

I would say the functional approach is definitely more idiomatic, especially if you have loops without side effects. This is different in Javascript, where iterators are eagerly executed, and so you loop over your data multiple times if you do filter().map(), but not in Rust. Here I would avoid explicit for loops if possible and also avoid side effects if possible, which for loops tend to invite you to introduce.

To be honest, the for_each() iterator was lazy by me. You could rewrite the whole function like that:

    pub fn find_entry_by_uuid(&self, id: Uuid) -> Option<&Entry> {
        self.children.iter().flat_map(|node| {
            match node {
                Node::Group(g) => g.find_entry_by_uuid(id),
                Node::Entry(e) => Some(e)
            }
        }).find(|entry| entry.uuid == id)
    }

Not only shorter, but also easier to read and understand. You don't come up with this kind of solution if you think in for loops, though.

[phoerious]

Another way to write it:

    pub fn find_entry_by_uuid(&self, id: Uuid) -> Option<&Entry> {
        self.children.iter().flat_map(|node| {
            match node {
                Node::Group(g) => g.find_entry_by_uuid(id),
                Node::Entry(e) => if e.uuid == id {
                    Some(e)
                } else {
                    None
                }
            }
        }).next()
    }

It's slightly longer, but avoids comparing uuids multiple times when walking up the recursion chain. Not sure if it makes a huge difference.

[phoerious]

This should be replaced with a recursive iterator implementation as suggested above.

[phoerious]

I read through the code a bit more. From what I understood, the NodeIter iterator is already recursive, but the traversal is breadth-first. By using a Vec<NodeRef<'a>> instead of a VecDeque<NodeRef<'a'>> as the internal traversal data structure, this could be changed to depth-first easily. Perhaps this could be extended to also include the full path.

[louib]

Superseded by #201