Questions/thoughts on ALOG style functions using CID

[RobStallion]

relates to #22

Insert

From what I can tell insert would remain largely unchanged. We would just swap inserting the UUID for a CID we make.

Please add thoughts on this if I have overlooked anything

Get

How do we want to handle someone calling get with an old/previous CID?

Do we want to...

• give a user the old version of the data?
• give the user the latest version of the data?
  • how do we want to access that data? Imagine the table below but with the same field edited 100 times. With the current fields in the table, if we were to try and serve the user the most recent version we would have to make about 100 get calls, where each one would return the 'next iteration' until the end of the line.
  • Do we keep the UUID as well as add the CID. This way we could still link all entries together and get the most recent version in one call? If we keep the UUID would this make the prev column redundant (as we would be able to tell the previous version from timestamps)
• give the user an error and have a separate function called get_previous (name tbd) that will handle returning old data?

Update

How do we want to handle someone calling the update function with an old/previous CID?

• do we update the most recent version? (same point as get when it comes to retrieving the old data)
• do we update the old version (I guess this would be similar to branching off)

---

inserted	cid(PK)1	name	address	prev
1541609554	gVSTedHFGBetxy	Bruce Wane	1007 Mountain Drive, Gotham	null
1541618643	smnELuCmEaX42	Bruce Wane	Rua Goncalo Afonso, Vila Madalena, Sao Paulo, 05436-100, Brazil	gVSTedHFGBetxy

[nelsonic]

@RobStallion thank you for opening this issue/question and sharing your thoughts! 😍

Understanding why we need to make the alog API changes requires insight into where we are going with our product development. Our Product is an "Activity Tracking" App which has the deliberately/deceptively simplistic name of "Time". ⏳

I plan on making a dent into clarifying this in the https://github.com/dwyl/product-roadmap over the weekend (family commitments 👫 and other demands 🏡 on my time permitting ...) 🔜

[nelsonic]

Content with Persistent entry_id for Ease of Querying

In order to make a record "queryable" it needs to have an "ID" that is consistent across rows/versions.
In this case we would use an entry_id which corresponds to a few characters of the cid.
Our Ecto adapter or query would need to be "smart" about this.
It would need to "check" if that entry_id already exists in the database.
If for example entry_id gV already exists in the database we would use the next character of the original cid e.g: gVS and so on until an unused entry_id is found.

inserted	cid(PK)1	name	address	prev	entry_id
1541609554	gVSTedHFGBetxy	Bruce Wane	1007 Mountain Drive, Gotham	null	gV
1541618643	smnELuCmEaX42	Bruce Wane	Rua Goncalo Afonso, Vila Madalena, Sao Paulo, 05436-100, Brazil	gVSTedHFGBetxy	gV
1541667890	alkjsnssuwnd123	Bruce Wane	10 Downing Street	smnELuCmEaX42	gV
1541098765	poiuyerfghnt345	Bruce Wane	10 Downing Street	alkjsnssuwnd123	bruce

Redirect Table:

If a user decides they want to have a human-friendly entry_id e.g: "bruce" instead of gV,
then we would need to have a entry_id_redirect table:

inserted	old_entry_id	current_entry_id
1541098765	gV	bruce

such that visiting: myaddressbook.com/gv
should redirect to myaddressbook.com/bruce

@RobStallion does this clarify how content can be queried?
If not, please ask further clarifying questions. thanks!