Enchancement Request: V5 Support

[grtiernan]

LiteDB V5 just recently came out. Would be great if you could release a version of the explorer that supports the opening of LiteDB V5 database files. Thanks in advance.

[julianpaulozzi]

Version 5 has its own "LiteDB Studio - Nice UI for data access". If you can list why do you prefer julianpaulozzi/LiteDbExplorer project?

[grtiernan]

Version 5 has its own "LiteDB Studio - Nice UI for data access". If you can list why do you prefer julianpaulozzi/LiteDbExplorer project?

The overall simplicity and effectiveness of LiteDB explorer is what had me using it for such a long time whilst I was developing with V4. LiteDB studio just still doesn't cut it for me right now.

It's useful for its own reasons, but as it stands it's very basic and takes extra effort just to access / query into a certain table within the database file. It has some interesting features but I don't really see myself using most of them to be perfectly honest.

With LiteDB Explorer we can just click and have ease of access of our database with a simple but effective user interface. It provides me with an easy way to click into tables in order to read data in the database file, as well as edit rows within it, which I find myself doing quite often while developing.

There's so much positives to LiteDB explorer to list, in comparison to LiteDB Studio. V5 does have some really great improvements that would be beneficial to my net core project, but I haven't updated yet because I can't quite bare not having LiteDB explorer. I'm sure I'm not the only one who would appreciate V5 support.

Anywho, I'll keep it short and sweet, but thanks for the response. Look forward to hearing back from you.

[julianpaulozzi]

Implement the ability to manipulate version 5 would have to improve and increase the abstraction to not create a large segmentation between features and versions. Which itself is not the biggest challenge since much has been abstracted in some way.

The biggest challenge is to have reference to 2 different versions of the same LiteDB assembly which leads me to see few options:

• Dynamically load the assembly and orchestrate the interactions to keep a single executable capable of interacting with both, who already dealt with it knows how complex and delicate it is, probably unfeasible.

• Create totally separate processes and a communication mechanism capable of interacting between them and the user interface. That way we would have several executables but we maintain a single UI. Very complicated too.

• Compile 2 different versions, each for its own version of LiteDB and increase the segmentation.

In all these cases we still have to improve the abstractions to avoid too much segmentation between features over database versions.

Any path would further increase complexity in a project that does not yet have a stable version even for LiteDB V4 and is in preview. Also we are not sure where LiteDB studio can go in the future.

When I fork the original project I used a lot of my free time implementing features to meet the needs of my use cases. I keep following this way as in the new export feature for Excel and CSV I had needed.

Currently the project does not have many external contributions and I have little free time.

Perhaps the best way would be to work in LiteDB Studio itself and take advantage of a larger number of contributors.

[marcbarry]

I'd agree with grtiernan's views, the simplicity and graphic user interface of LiteDB Explorer makes it a pleasure to work with. Quick access to graphically view and edit rows are super important. A large factor in the decision use LiteDB as a data store for me, was because of how easy LiteDB Explorer made it to interrogate that data store.

[darcome]

Hi, I like LiteDB Explorer too! Please continue to work on it!

[optimus-code]

I concur, LiteDbExplorer is a great tool, it is very promising and is the best LiteDB tool out there.

[mzhukovs]

LiteDB v5 RC out on nuget!