Is there a reason that the Solidus team didn't implement soft-deletes on the Spree::Order or Spree::LineItem tables?

Deleting orders is a pretty rare thing. Mostly they just get cancelled.

@Jared Norman you are right.. updating an order though is common. We have an ETL process that dumps data in BigQuery for analysis. It's difficult to determine which line items though are correct though given that the update_cart API

I don’t know if it would make sense to soft delete a line item, but I could see a use case for soft deleting an order

yeah, it would actually be really nice to have soft deletion on orders to track merged orders better

@Kevin I the way I’ve seen this dealt with on a project is by having a field added to each table in BigQuery for

_deleted

and managing that in the data warehouse. IIRC this is going to be an issue not just for the orders/line items tables but probably all other tables as well. I am not sure if this is a common pattern but on said project that was present on all tables.

Hey @Chris Todorov yes this works perfectly with the Discard gem which adds a discarded_at column that we can query against instead of deleting and that's really the nature of this discussion. The SoftDelete module has been added to a lot of different models in Solidus but not to Spree::LineItem which is where I would like to see it so it doesn't support deleting by using this discarded_at field and it doesn't scope queries to non-deleted items accordingly. So the the request is really to do just as your saying on these models as well.

I guess one concern with that approach I have would be the massive amount of data you may end up keeping as users add/remove things from their cart. On a busy store that may explode your line items table.

@Chris Todorov how would the datawarehouse know if something was deleted?

I guess one approach would be the next time a given order is sync’d to Big Query any line items not present on it can be marked as deleted.

Ahh I see what you are saying

I haven’t actually had to set that up in an ETL, but only had to consume data from Big Query and I believe that’s how that was handled.

I guess that makense sense.. if all line_items of updated_at timestamp are updated to the same value whenever an order is updated than you can simply run a cleaning routine that purges any line_items that aren't on the latest updated_at timestamp