You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be possible to simply add an expires column to the table definition?
Instead of marshalling and adding it somehow into the k/v, just use that col to check if the entry has expired.
Is there some reason why it was not done this way?
The text was updated successfully, but these errors were encountered:
I think you are right that this would be possible -- the mongo adapter does something similar to this. If you feel like contributing a patch that does this, I think it would be gratefully received.
The only gotcha would be providing compatibility for people who have a table created with a previous version -- perhaps a migration, or a fallback for when the column is missing.
Having had a further think about this, I think the best way to implement this sort of thing would be to allow adapters to indicate that they support a "metadata" feature. The SQL-based adapters can do this via additional columns; the document stores via additional keys, etc. A wrapper class could be provided to give metadata support where the adapter does not support it natively (similar to the existing Expires wrapper). Metadata could include details such as a creation time, update time, user details, geographic details, etc.
Fallback support for expiry (where not natively supported) could then be implemented on top of this metadata functionality. In the SQL adapters, this would ultimately mean that a row's expiry could be stored in a specific column.
Would it be possible to simply add an expires column to the table definition?
Instead of marshalling and adding it somehow into the k/v, just use that col to check if the entry has expired.
Is there some reason why it was not done this way?
The text was updated successfully, but these errors were encountered: