Oops, touch list updated_at when adding/removing items

Oh right, I forgot that 2020 has endpoints to add/remove items from
lists, so I didn't add logic that corresponds to the `touch: true` we
recently added in the Rails app to power caching!

This created a bug where adding/removing items from lists from the item
page would _not_ cause the cache to update in the Rails app when
sharing your list with others.

In this change, we add `UPDATE` queries to emulate that same logic!
This commit is contained in:
Emi Matchu 2024-03-09 11:51:00 -08:00
parent eb915ae851
commit 584fed70c6

View file

@ -1138,6 +1138,14 @@ const resolvers = {
[itemId, userId, ownsOrWantsItems === "OWNS", listId, 1, now, now],
);
// Finally, touch the `updated_at` timestamp for the list.
await connection.query(
`
UPDATE closet_lists SET updated_at = ? WHERE id = ? LIMIT 1;
`,
[now, listId],
);
await connection.commit();
} catch (error) {
try {
@ -1182,6 +1190,9 @@ const resolvers = {
const connection = await db.getConnection();
try {
await connection.beginTransaction();
const now = new Date();
// First, remove the hanger from the list.
await connection.query(
`
DELETE FROM closet_hangers
@ -1190,6 +1201,16 @@ const resolvers = {
[...listMatcherValues, itemId],
);
// Then, touch the `updated_at` timestamp for the list.
if (!closetListRef.isDefaultList) {
await connection.query(
`
UPDATE closet_lists SET updated_at = ? WHERE id = ? LIMIT 1;
`,
[now, closetListRef.id],
);
}
if (ensureInSomeList) {
// If requested, we check whether the item is still in *some* list of
// the same own/want type. If not, we add it to the default list.
@ -1202,7 +1223,6 @@ const resolvers = {
);
if (rows[0].count === 0) {
const now = new Date();
await connection.query(
`
INSERT INTO closet_hangers
@ -1221,6 +1241,8 @@ const resolvers = {
} catch (error) {
console.warn(`Error rolling back transaction`, error);
}
throw error;
} finally {
await connection.release();
}