# Pastebin smv2fuvT
## Title
It seems that the main part will be to archive external URLs, not to generate bindings. The title should reflect this.

## Project Overview
The term “relationships” has a specific meaning in MB. There is no “URL relationships” in edit notes, just URLs. See https://musicbrainz.org/doc/Relationships

The content of `edit_data` is relevant only for a few `edit.type`. See https://musicbrainz.org/doc/Edit_Types

Changes to existing edit notes are in the table `edit_note_change`.

## 1A
Some of your changes are MB specific thus keeping a fork makes sense, but the rest should be contributed back to the original repository if possible as the author is active and welcoming contributions and feedback.

## 1B
It will be helpful with making `SELECT` queries mostly as there can be additional constraints when modifying the database.

## 1C
The goals of this abstraction are very unclear. Will it still be possible to regenerate the bindings?

If it isn’t needed for the URL archiver, I would highly recommend to move it to the stretch goals.

## 2A
Starting with the easiest solution is fine. It can improved later on.

## 2B
New versions of Redis are no longer open source, but we are considering open source alternatives that are compatible, possibly the fork Redict.

## 2C
Decoupling parts is the key.

## Timeline
It is way too abstract. It contains a lot interesting points that can be useful to work on to make the app as a final goal, but what is expected for each step is most often very unclear.

I would rather recommend to have small intermediate actionnable goals.

Further splitting your app into logical parts can also help with planning.

Documentation and tests should ideally be written as coding.