Introduce generalized `DataStore` by tnull · Pull Request #544 · lightningdevkit/ldk-node

tnull · 2025-05-20T14:39:13Z

We already have a 'store' pattern in a few places in our codebase (peer store, payment store), and for #425 we're about to add yet another one. To at least somewhat DRY up the storage logic, we here introduce a generalized DataStore and migrate our PaymentStore to it. This is a prefactor to #425.

(cc @moisesPompilio)

ldk-reviews-bot · 2025-05-20T14:39:16Z

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

jkczyz · 2025-05-20T20:16:05Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


Does the order matter here? The opposite order is used in insert_or_update, so there we could have the object in memory but fail persisting.

Hmm, this one used to be the other way around, but I changed it here (actually should be the only behavioral diff I snuck in, IIRC), exactly because it would be preferable to not update the in-memory version if persistence failed. However, for insert_or_update/update we won't know whether the update is necessary at all until StorableObject::update returns, which is why we unfortunately can't first persist.

For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

Yeah, we could do that eventually, although it probably would somehow need to fit into a "halt everything on (remote) persistence failure, and resume/restart once we reestablish connectivity" scheme.

jkczyz

LGTM after squash.

jkczyz · 2025-05-21T15:52:48Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

tnull · 2025-05-21T17:45:27Z

LGTM after squash.

Squashed without further changes.

We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

jkczyz

Not sure if CI failure is flakiness.

tnull · 2025-05-21T18:22:03Z

Not sure if CI failure is flakiness.

Should be, I re-ran CI, will merge if it passes.

tnull · 2025-05-20T14:39:13Z

We already have a 'store' pattern in a few places in our codebase (peer store, payment store), and for #425 we're about to add yet another one. To at least somewhat DRY up the storage logic, we here introduce a generalized DataStore and migrate our PaymentStore to it. This is a prefactor to #425.

(cc @moisesPompilio)

ldk-reviews-bot · 2025-05-20T14:39:16Z

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

jkczyz · 2025-05-20T20:16:05Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


Does the order matter here? The opposite order is used in insert_or_update, so there we could have the object in memory but fail persisting.

Hmm, this one used to be the other way around, but I changed it here (actually should be the only behavioral diff I snuck in, IIRC), exactly because it would be preferable to not update the in-memory version if persistence failed. However, for insert_or_update/update we won't know whether the update is necessary at all until StorableObject::update returns, which is why we unfortunately can't first persist.

For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

Yeah, we could do that eventually, although it probably would somehow need to fit into a "halt everything on (remote) persistence failure, and resume/restart once we reestablish connectivity" scheme.

jkczyz

LGTM after squash.

jkczyz · 2025-05-21T15:52:48Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

tnull · 2025-05-21T17:45:27Z

LGTM after squash.

Squashed without further changes.

We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

jkczyz

Not sure if CI failure is flakiness.

tnull · 2025-05-21T18:22:03Z

Not sure if CI failure is flakiness.

Should be, I re-ran CI, will merge if it passes.

tnull · 2025-05-20T14:39:13Z

We already have a 'store' pattern in a few places in our codebase (peer store, payment store), and for #425 we're about to add yet another one. To at least somewhat DRY up the storage logic, we here introduce a generalized DataStore and migrate our PaymentStore to it. This is a prefactor to #425.

(cc @moisesPompilio)

ldk-reviews-bot · 2025-05-20T14:39:16Z

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

jkczyz · 2025-05-20T20:16:05Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


Does the order matter here? The opposite order is used in insert_or_update, so there we could have the object in memory but fail persisting.

Hmm, this one used to be the other way around, but I changed it here (actually should be the only behavioral diff I snuck in, IIRC), exactly because it would be preferable to not update the in-memory version if persistence failed. However, for insert_or_update/update we won't know whether the update is necessary at all until StorableObject::update returns, which is why we unfortunately can't first persist.

For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

Yeah, we could do that eventually, although it probably would somehow need to fit into a "halt everything on (remote) persistence failure, and resume/restart once we reestablish connectivity" scheme.

jkczyz

LGTM after squash.

jkczyz · 2025-05-21T15:52:48Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

tnull · 2025-05-21T17:45:27Z

LGTM after squash.

Squashed without further changes.

We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

jkczyz

Not sure if CI failure is flakiness.

tnull · 2025-05-21T18:22:03Z

Not sure if CI failure is flakiness.

Should be, I re-ran CI, will merge if it passes.

tnull · 2025-05-20T14:39:13Z

We already have a 'store' pattern in a few places in our codebase (peer store, payment store), and for #425 we're about to add yet another one. To at least somewhat DRY up the storage logic, we here introduce a generalized DataStore and migrate our PaymentStore to it. This is a prefactor to #425.

(cc @moisesPompilio)

ldk-reviews-bot · 2025-05-20T14:39:16Z

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

jkczyz · 2025-05-20T20:16:05Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


Does the order matter here? The opposite order is used in insert_or_update, so there we could have the object in memory but fail persisting.

Hmm, this one used to be the other way around, but I changed it here (actually should be the only behavioral diff I snuck in, IIRC), exactly because it would be preferable to not update the in-memory version if persistence failed. However, for insert_or_update/update we won't know whether the update is necessary at all until StorableObject::update returns, which is why we unfortunately can't first persist.

For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

Yeah, we could do that eventually, although it probably would somehow need to fit into a "halt everything on (remote) persistence failure, and resume/restart once we reestablish connectivity" scheme.

jkczyz

LGTM after squash.

jkczyz · 2025-05-21T15:52:48Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

tnull · 2025-05-21T17:45:27Z

LGTM after squash.

Squashed without further changes.

We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

jkczyz

Not sure if CI failure is flakiness.

tnull · 2025-05-21T18:22:03Z

Not sure if CI failure is flakiness.

Should be, I re-ran CI, will merge if it passes.

tnull · 2025-05-20T14:39:13Z

We already have a 'store' pattern in a few places in our codebase (peer store, payment store), and for #425 we're about to add yet another one. To at least somewhat DRY up the storage logic, we here introduce a generalized DataStore and migrate our PaymentStore to it. This is a prefactor to #425.

(cc @moisesPompilio)

ldk-reviews-bot · 2025-05-20T14:39:16Z

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

jkczyz · 2025-05-20T20:16:05Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


Does the order matter here? The opposite order is used in insert_or_update, so there we could have the object in memory but fail persisting.

Hmm, this one used to be the other way around, but I changed it here (actually should be the only behavioral diff I snuck in, IIRC), exactly because it would be preferable to not update the in-memory version if persistence failed. However, for insert_or_update/update we won't know whether the update is necessary at all until StorableObject::update returns, which is why we unfortunately can't first persist.

For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

Yeah, we could do that eventually, although it probably would somehow need to fit into a "halt everything on (remote) persistence failure, and resume/restart once we reestablish connectivity" scheme.

jkczyz

LGTM after squash.

jkczyz · 2025-05-21T15:52:48Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

tnull · 2025-05-21T17:45:27Z

LGTM after squash.

Squashed without further changes.

We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

jkczyz

Not sure if CI failure is flakiness.

tnull · 2025-05-21T18:22:03Z

Not sure if CI failure is flakiness.

Should be, I re-ran CI, will merge if it passes.

tnull · 2025-05-20T14:39:13Z

We already have a 'store' pattern in a few places in our codebase (peer store, payment store), and for #425 we're about to add yet another one. To at least somewhat DRY up the storage logic, we here introduce a generalized DataStore and migrate our PaymentStore to it. This is a prefactor to #425.

(cc @moisesPompilio)

ldk-reviews-bot · 2025-05-20T14:39:16Z

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

jkczyz · 2025-05-20T20:16:05Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


Does the order matter here? The opposite order is used in insert_or_update, so there we could have the object in memory but fail persisting.

Hmm, this one used to be the other way around, but I changed it here (actually should be the only behavioral diff I snuck in, IIRC), exactly because it would be preferable to not update the in-memory version if persistence failed. However, for insert_or_update/update we won't know whether the update is necessary at all until StorableObject::update returns, which is why we unfortunately can't first persist.

For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

Yeah, we could do that eventually, although it probably would somehow need to fit into a "halt everything on (remote) persistence failure, and resume/restart once we reestablish connectivity" scheme.

jkczyz

LGTM after squash.

jkczyz · 2025-05-21T15:52:48Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

tnull · 2025-05-21T17:45:27Z

LGTM after squash.

Squashed without further changes.

We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

jkczyz

Not sure if CI failure is flakiness.

tnull · 2025-05-21T18:22:03Z

Not sure if CI failure is flakiness.

Should be, I re-ran CI, will merge if it passes.

tnull · 2025-05-20T14:39:13Z

We already have a 'store' pattern in a few places in our codebase (peer store, payment store), and for #425 we're about to add yet another one. To at least somewhat DRY up the storage logic, we here introduce a generalized DataStore and migrate our PaymentStore to it. This is a prefactor to #425.

(cc @moisesPompilio)

ldk-reviews-bot · 2025-05-20T14:39:16Z

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

jkczyz · 2025-05-20T20:16:05Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


Does the order matter here? The opposite order is used in insert_or_update, so there we could have the object in memory but fail persisting.

Hmm, this one used to be the other way around, but I changed it here (actually should be the only behavioral diff I snuck in, IIRC), exactly because it would be preferable to not update the in-memory version if persistence failed. However, for insert_or_update/update we won't know whether the update is necessary at all until StorableObject::update returns, which is why we unfortunately can't first persist.

For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

Yeah, we could do that eventually, although it probably would somehow need to fit into a "halt everything on (remote) persistence failure, and resume/restart once we reestablish connectivity" scheme.

jkczyz

LGTM after squash.

jkczyz · 2025-05-21T15:52:48Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

tnull · 2025-05-21T17:45:27Z

LGTM after squash.

Squashed without further changes.

We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

jkczyz

Not sure if CI failure is flakiness.

tnull · 2025-05-21T18:22:03Z

Not sure if CI failure is flakiness.

Should be, I re-ran CI, will merge if it passes.

tnull · 2025-05-20T14:39:13Z

We already have a 'store' pattern in a few places in our codebase (peer store, payment store), and for #425 we're about to add yet another one. To at least somewhat DRY up the storage logic, we here introduce a generalized DataStore and migrate our PaymentStore to it. This is a prefactor to #425.

(cc @moisesPompilio)

ldk-reviews-bot · 2025-05-20T14:39:16Z

👋 Thanks for assigning @jkczyz as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

jkczyz · 2025-05-20T20:16:05Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


Does the order matter here? The opposite order is used in insert_or_update, so there we could have the object in memory but fail persisting.

Hmm, this one used to be the other way around, but I changed it here (actually should be the only behavioral diff I snuck in, IIRC), exactly because it would be preferable to not update the in-memory version if persistence failed. However, for insert_or_update/update we won't know whether the update is necessary at all until StorableObject::update returns, which is why we unfortunately can't first persist.

For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

Yeah, we could do that eventually, although it probably would somehow need to fit into a "halt everything on (remote) persistence failure, and resume/restart once we reestablish connectivity" scheme.

jkczyz

LGTM after squash.

jkczyz · 2025-05-21T15:52:48Z

+ self.persist(&object)?;
+ let updated = locked_objects.insert(object.id(), object).is_some();


For insert_or_update/update, it seems we log an error but continue. I suppose this predates the PR, but I wonder if we should do something else like have a queue of ids that still need persistence. Though if we eventually crash that information would be loss. Maybe this is more of a storage implementation concern.

tnull · 2025-05-21T17:45:27Z

LGTM after squash.

Squashed without further changes.

We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

jkczyz

Not sure if CI failure is flakiness.

tnull · 2025-05-21T18:22:03Z

Not sure if CI failure is flakiness.

Should be, I re-ran CI, will merge if it passes.

tnull requested a review from jkczyz May 20, 2025 14:39

jkczyz reviewed May 20, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from f29bdd3 to 6fa3502Compare May 21, 2025 07:44

tnull requested a review from jkczyz May 21, 2025 07:44

jkczyz reviewed May 21, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from 6fa3502 to 0561bc4Compare May 21, 2025 17:45

tnull added 2 commits May 21, 2025 19:46

Add generic DataStore
93622f7
We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

Refactor PaymentStore to use DataStore
75aa069
.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

tnull force-pushed the 2025-05-generalized-data-store branch from 0561bc4 to 75aa069Compare May 21, 2025 17:46

jkczyz approved these changes May 21, 2025
View reviewed changes

tnull merged commit 9151340 into lightningdevkit:mainMay 21, 2025

joostjager mentioned this pull request Jun 9, 2025
Cut 0.6.0 Rust release #568
Merged

tnull requested a review from jkczyz May 20, 2025 14:39

jkczyz reviewed May 20, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from f29bdd3 to 6fa3502Compare May 21, 2025 07:44

tnull requested a review from jkczyz May 21, 2025 07:44

jkczyz reviewed May 21, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from 6fa3502 to 0561bc4Compare May 21, 2025 17:45

tnull added 2 commits May 21, 2025 19:46

Add generic DataStore
93622f7
We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

Refactor PaymentStore to use DataStore
75aa069
.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

tnull force-pushed the 2025-05-generalized-data-store branch from 0561bc4 to 75aa069Compare May 21, 2025 17:46

jkczyz approved these changes May 21, 2025
View reviewed changes

tnull merged commit 9151340 into lightningdevkit:mainMay 21, 2025

joostjager mentioned this pull request Jun 9, 2025
Cut 0.6.0 Rust release #568
Merged

tnull requested a review from jkczyz May 20, 2025 14:39

jkczyz reviewed May 20, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from f29bdd3 to 6fa3502Compare May 21, 2025 07:44

tnull requested a review from jkczyz May 21, 2025 07:44

jkczyz reviewed May 21, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from 6fa3502 to 0561bc4Compare May 21, 2025 17:45

tnull added 2 commits May 21, 2025 19:46

Add generic DataStore
93622f7
We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

Refactor PaymentStore to use DataStore
75aa069
.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

tnull force-pushed the 2025-05-generalized-data-store branch from 0561bc4 to 75aa069Compare May 21, 2025 17:46

jkczyz approved these changes May 21, 2025
View reviewed changes

tnull merged commit 9151340 into lightningdevkit:mainMay 21, 2025

joostjager mentioned this pull request Jun 9, 2025
Cut 0.6.0 Rust release #568
Merged

tnull requested a review from jkczyz May 20, 2025 14:39

jkczyz reviewed May 20, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from f29bdd3 to 6fa3502Compare May 21, 2025 07:44

tnull requested a review from jkczyz May 21, 2025 07:44

jkczyz reviewed May 21, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from 6fa3502 to 0561bc4Compare May 21, 2025 17:45

tnull added 2 commits May 21, 2025 19:46

Add generic DataStore
93622f7
We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

Refactor PaymentStore to use DataStore
75aa069
.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

tnull force-pushed the 2025-05-generalized-data-store branch from 0561bc4 to 75aa069Compare May 21, 2025 17:46

jkczyz approved these changes May 21, 2025
View reviewed changes

tnull merged commit 9151340 into lightningdevkit:mainMay 21, 2025

joostjager mentioned this pull request Jun 9, 2025
Cut 0.6.0 Rust release #568
Merged

tnull requested a review from jkczyz May 20, 2025 14:39

jkczyz reviewed May 20, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from f29bdd3 to 6fa3502Compare May 21, 2025 07:44

tnull requested a review from jkczyz May 21, 2025 07:44

jkczyz reviewed May 21, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from 6fa3502 to 0561bc4Compare May 21, 2025 17:45

tnull added 2 commits May 21, 2025 19:46

Add generic DataStore
93622f7
We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

Refactor PaymentStore to use DataStore
75aa069
.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

tnull force-pushed the 2025-05-generalized-data-store branch from 0561bc4 to 75aa069Compare May 21, 2025 17:46

jkczyz approved these changes May 21, 2025
View reviewed changes

tnull merged commit 9151340 into lightningdevkit:mainMay 21, 2025

joostjager mentioned this pull request Jun 9, 2025
Cut 0.6.0 Rust release #568
Merged

tnull requested a review from jkczyz May 20, 2025 14:39

jkczyz reviewed May 20, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from f29bdd3 to 6fa3502Compare May 21, 2025 07:44

tnull requested a review from jkczyz May 21, 2025 07:44

jkczyz reviewed May 21, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from 6fa3502 to 0561bc4Compare May 21, 2025 17:45

tnull added 2 commits May 21, 2025 19:46

Add generic DataStore
93622f7
We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

Refactor PaymentStore to use DataStore
75aa069
.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

tnull force-pushed the 2025-05-generalized-data-store branch from 0561bc4 to 75aa069Compare May 21, 2025 17:46

jkczyz approved these changes May 21, 2025
View reviewed changes

tnull merged commit 9151340 into lightningdevkit:mainMay 21, 2025

joostjager mentioned this pull request Jun 9, 2025
Cut 0.6.0 Rust release #568
Merged

tnull requested a review from jkczyz May 20, 2025 14:39

jkczyz reviewed May 20, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from f29bdd3 to 6fa3502Compare May 21, 2025 07:44

tnull requested a review from jkczyz May 21, 2025 07:44

jkczyz reviewed May 21, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from 6fa3502 to 0561bc4Compare May 21, 2025 17:45

tnull added 2 commits May 21, 2025 19:46

Add generic DataStore
93622f7
We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

Refactor PaymentStore to use DataStore
75aa069
.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

tnull force-pushed the 2025-05-generalized-data-store branch from 0561bc4 to 75aa069Compare May 21, 2025 17:46

jkczyz approved these changes May 21, 2025
View reviewed changes

tnull merged commit 9151340 into lightningdevkit:mainMay 21, 2025

joostjager mentioned this pull request Jun 9, 2025
Cut 0.6.0 Rust release #568
Merged

tnull requested a review from jkczyz May 20, 2025 14:39

jkczyz reviewed May 20, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from f29bdd3 to 6fa3502Compare May 21, 2025 07:44

tnull requested a review from jkczyz May 21, 2025 07:44

jkczyz reviewed May 21, 2025
View reviewed changes

tnull force-pushed the 2025-05-generalized-data-store branch from 6fa3502 to 0561bc4Compare May 21, 2025 17:45

tnull added 2 commits May 21, 2025 19:46

Add generic DataStore
93622f7
We increasingly feature different data stores that essentially do the same thing, mod different data types. Here we add a generalized `DataStore` that will be used to DRY up our logic.

Refactor PaymentStore to use DataStore
75aa069
.. we utilize the just-introduced generalized `DataStore` for our `PaymentStore`.

tnull force-pushed the 2025-05-generalized-data-store branch from 0561bc4 to 75aa069Compare May 21, 2025 17:46

jkczyz approved these changes May 21, 2025
View reviewed changes

tnull merged commit 9151340 into lightningdevkit:mainMay 21, 2025

joostjager mentioned this pull request Jun 9, 2025
Cut 0.6.0 Rust release #568
Merged

		self.persist(&object)?;
		let updated = locked_objects.insert(object.id(), object).is_some();

Uh oh!

Conversation

tnull commented May 20, 2025

Uh oh!

ldk-reviews-bot commented May 20, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull commented May 21, 2025

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

tnull commented May 21, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

tnull commented May 20, 2025

Uh oh!

ldk-reviews-bot commented May 20, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnull commented May 21, 2025

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

tnull commented May 21, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ldk-reviews-bot commented May 20, 2025•
edited
Loading

ldk-reviews-bot commented May 20, 2025•
edited
Loading

ldk-reviews-bot commented May 20, 2025•
edited
Loading