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
clocker's internals could be reworked to write operations into an append-only log with hyperlog so that the clocker database can easily be replicated among different machines or across teams of people. The existing command-line interfaces can largely be preserved with a few small modifications to deal with occasional multi-value records. The list and data commands can read from a materialized view of the data created by a hyperlog index.
There was some discussion of this feature already in #12. If nothing else, this would be a very useful backup feature, and this indexing scheme will make it easier to generate different views of the underlying data in the future. This feature should also be integrated with a migration script to automatically port existing data into the new format.
The text was updated successfully, but these errors were encountered:
I would prefer to first discuss a list of goals we want to achieve with clocker. Currently I like it especially for its CLI and simplicity. For my personal use I only need a way to work across multiple machines, either by a git-like pull/push workflow or by a silently shared database. Plus even better CLI interfaces to pipe clocker's output to tools like cli-gh-cal. I would expect that teams would prefer some other time tracking tool.
clocker's internals could be reworked to write operations into an append-only log with hyperlog so that the clocker database can easily be replicated among different machines or across teams of people. The existing command-line interfaces can largely be preserved with a few small modifications to deal with occasional multi-value records. The list and data commands can read from a materialized view of the data created by a hyperlog index.
There was some discussion of this feature already in #12. If nothing else, this would be a very useful backup feature, and this indexing scheme will make it easier to generate different views of the underlying data in the future. This feature should also be integrated with a migration script to automatically port existing data into the new format.
The text was updated successfully, but these errors were encountered: