Feature Request: Persist to/Read from CSV/TSV about logseq-plugin-luckysheet HOT 15 CLOSED

Great suggestion! In fact, I always wanted to store the content in the assets folder, but it wasn't supported by the Logseq plugin SDK. Storing in markdown is kind of a workaround solution. The good news is, with the release of Logseq 0.8.9, there is a new plugin SDK API that allows to write in the assets folder. I still need to spend some time to test it, once it's assessed, I'll change the save to write to the assets folder and remove markdown storing.

Regarding CSV, it is not a feature rich file format, so many features like formatting, formulas, etc, are not possible with it. Given this restriction, I'm not sure storing in CSV by default is a good idea.

What I can do I think, is to provide an "import/export" functionality. BTW, I think you can already paste a CSV into Luckysheet and use the "Copy selection as TSV" button to "export" the content in TSV.

from logseq-plugin-luckysheet.

@yingzhu146 @rebron1900 , I have released a new version v0.9.0 which stores the content in the assets folder of your graph, please have a look. 我发布了新版本 v0.9.0，现在内容会存到你图的 assets 文件夹内。存储数据会在你保存时自动处理，请尝试。

from logseq-plugin-luckysheet.

Above is where the files are in your graph, just find them by the workbook name you used in Logseq.

Regarding the file format, think of the file stored as an Excel file (.xlsx), there is no such thing as the separation of data and the so called "metadata". And like I said before, CSV can not be used as the default file format, it has no ability to represent a Luckysheet sheet.

As of the interoperability with the other softwares, you can use the provided "copy selection as TSV" button to export your data in the TSV format. Later, I'll implement a TSV paste feature for importing as well.

from logseq-plugin-luckysheet.

You're welcome to make your own implementations. 😉

from logseq-plugin-luckysheet.

That makes a lot of sense! For my particular use case, any file format that is somewhat standardized/readable would work.

You could also e.g. store all data in CSV/TSV/sqlite/... and have luckysheet required metadata in an associated json/edn - which is also how pdf annotations are handled so seems nice/consistent

from logseq-plugin-luckysheet.

0.8.9中不能保存数据到子块的json中了，如图，表格中有数据，但是在往常储存数据的json中没有发生数据变化。：

from logseq-plugin-luckysheet.

Amazing thank you - what is it saved as? code looks like json but grepping for json (or csv...) comes up empty handed. tried reinstalling & restarting but no dice

from logseq-plugin-luckysheet.

It's JSON, but it's not two dimensional. It contains all the data and metadata Luckysheet uses.

from logseq-plugin-luckysheet.

@sethyuan thks，i will try to update 0.9.0，The changes to solved many problems.

from logseq-plugin-luckysheet.

BTW, you need to use Logseq v0.8.9+ in order to use the 0.9.0.

from logseq-plugin-luckysheet.

doesn't seem to work for me - version 0.9.0, logseq 0.8.9

$ pwd
 /Users/yingzhu/Library/Mobile Documents/iCloud~com~logseq~logseq/Documents/assets
$ find ./ -name '*.pdf' | wc -l
    1506
$ find ./ -name '*.json' | wc -l
       0

from logseq-plugin-luckysheet.

File is stored in your graph's assets folder and they have no extension.

from logseq-plugin-luckysheet.

Yes - this is my graph's assets folder. How do I find the file given a workbook?

Also - really appreciate the fast implementation of persisting JSON metadata of luckysheet - a very useful feature!

BUT - I don't think this feature request should be closed - this was about syncing from/to a standard tabular file format that is editable by another spreadsheet software (like the other logseq file formats like PDF, Markdown, EDN are editable/usable in non-logseq software), not about persisting luckysheet metadata in the assets folder (which is good! but not the feature request here).

I would prefer an implementation that separates luckysheet meta info (which I don't care all too much about) from the tabular data (which I want easily accessible in a standard spreadsheet format to minimize lock-in) - identical to how e.g. PDF annotations are handled (content [pdf] stored separately from metainfo/annotations [hls])

from logseq-plugin-luckysheet.

Thank you! I didn't think it might be in a folder since all other assets are non-nested afaict

Regarding the file format, think of the file stored as an Excel file (.xlsx), there is no such thing as the separation of data and the so called "metadata".

Yes exactly - which is why Excel is a very bad thing to emulate and against Logseq philosophy :) (using proprietary & non-standard formats which cause lock in - this is why logseq exclusively uses non-proprietary/portable formats wherever possible - PDF, markdown, orgmode, png, jpg. Which is why e.g. you can easily open a logseq graph in obsidian/craft/your_favorite_markdown_editor)

And like I said before, CSV can not be used as the default file format, it has no ability to represent a Luckysheet sheet.

Of course it can - you just need to separate metadata from content - that's exactly how PDF annotations are implemented. the content is stored in the standard PDF format, while annotations are stored in a hls__*.md. To provide the annotation features, logseq reads these two files.

Analogously, you could easily implement luckysheet such that there's a meta_$WORKBOOK.md/json/edn which contains metadata required to represent a luckysheet sheet, and then a sheet$INDEX_$WORKBOOK.csv file which contains the contents for sheet X.

As of the interoperability with the other softwares, you can use the provided "copy selection as TSV" button to export your data in the TSV format. Later, I'll implement a TSV paste feature for importing as well.

That doesn't solve my use case (avoiding lock in & enabling re-use of the content across software).

Imagine I have 5'000 luckysheet tables and I want to migrate their data from logseq to a database management tool (most of which will be able to load data from csv's)
With the current method I will need to

• read & understand your code
• re-engineer the json schema
• write a parser
• parse files into CSV.

Now imagine I want to actually keep using both logseq and this database tool in parallel, which means I need to keep them in sync, so I would additionally need to

• come up with a synchronization strategy
• write a file watcher to run the parser on every save operation

This is a ton of work & leads to unnecessary content duplication

With the implementation I propose you would have to do:

• literally nothing :) - just load/import the CSV. It's guaranteed to be 1) synced 2) portable

Now - all that said - completely okay for you to just say you don't want to solve this use case - but this was the feature request

from logseq-plugin-luckysheet.

Fair enough! :) thanks for implementing the local persistence so quickly!

from logseq-plugin-luckysheet.