OK what would happen if we use our uri table as our lookup table and add the above table as the uri_tracking_table
Another though would be actually to have the normal uri_table and a new update_uri_table
where we link and id to its new id
so moving foo to bar will give us
============================
id | value
---------------
1 | foo.txt
2 | bar.txt
id | new_value_id
-----------------------
1 | 2
now in case we move bar.txt to lol.txt we just update the DB again by checking the all value_ids = 2 and change it to 3 and add a new row...
id | value
---------------
1 | foo.txt
2 | bar.txt
3 | lol.txt
id | new_value_id
-----------------------
1 | 3
2 | 3
so if the user asks for raw events we do what we always did
if the user asks for updated events (updated subject_uris) we will need to join once... It comes with a cost of performance but I think we can handle it
We need to actually sprint on that issue.
I marked this as effecting Unity since when I move a file i don see it in unity anymore
OK what would happen if we use our uri table as our lookup table and add the above table as the uri_tracking_table
Another though would be actually to have the normal uri_table and a new update_uri_table
where we link and id to its new id
so moving foo to bar will give us ======= ======= =======
=======
id | value
---------------
1 | foo.txt
2 | bar.txt
id | new_value_id ------- ------- --
-------
1 | 2
now in case we move bar.txt to lol.txt we just update the DB again by checking the all value_ids = 2 and change it to 3 and add a new row...
id | value
---------------
1 | foo.txt
2 | bar.txt
3 | lol.txt
id | new_value_id ------- ------- --
-------
1 | 3
2 | 3
so if the user asks for raw events we do what we always did
if the user asks for updated events (updated subject_uris) we will need to join once... It comes with a cost of performance but I think we can handle it
We need to actually sprint on that issue.
I marked this as effecting Unity since when I move a file i don see it in unity anymore