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
As fselect is SQL oriented, could a SQLite backend be conceivable as an alternate direct output format for storing and querying fselect results? Many use cases would be possible for having a better knowledge of a might be large dataset. SQLite could be easily updated from a new run of fselect. Importing into SQLite from CSV files is not ideal.
What's your feeling about it?
Thanks
The text was updated successfully, but these errors were encountered:
Hi, that's an interesting question, what should be a backed for what :) While importing CSV or JSON is not ideal (but pretty straightforward) operation, exposing fselect's functionality as a virtual table provider might be more profitable solution. Here we get joins and other SQL goodies for free.
Hi,
sorry for the late answer. Default output might end into a SQLite table for convenience for avoiding retraversing thousand if not millions of folders and extracting metadata from files. So for the (lazy) admin, having an SQLite export would be quite useful, something like fselect name, abspath, user from . into whatever.sqlite. Maybe an upsert? Rust is well equiped for this backend! Thanks
Hi,
As fselect is SQL oriented, could a SQLite backend be conceivable as an alternate direct output format for storing and querying fselect results? Many use cases would be possible for having a better knowledge of a might be large dataset. SQLite could be easily updated from a new run of fselect. Importing into SQLite from CSV files is not ideal.
What's your feeling about it?
Thanks
The text was updated successfully, but these errors were encountered: