[LevelDbStore] Updated features & Usability of Interop

[cschuchardt88]

Change Log

• Enabled all the features of leveldb
• New Classes, Memory management and interoperability.

Type of change

• Optimization (the change is only an optimization)
• Style (the change is only a code style for better maintenance or standard purpose)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[Jim8y]

change like this better split into multiple small tasks and start working on a specific branch.

[cschuchardt88]

Why is so hard for you review a PR? No more than 10 lines, everyone throws a fit. It an application as a whole. No one is going to approve a PR if it doesn't work or incomplete application. It like me making a PR for a HelloWorld console app. Even if it was on another branch it not going to get approve until years and could even be forgot. Do it right the 1st time and I wouldn't need to clean up. There is no thought put into code design. Not my fault and everyone wonders why no one uses it. So stop saying small PR. Small PRs are for bug fixes. How are we to expand? Plus I am moving this from neo-modules. My code is straight forward and easy to follow. Sorry for out burst but its at everyone not you @Jim8y.

[Jim8y]

i have being following with this issue for a while, and have discussed with multiple coredevs, turns out everyone is actually working hard and busy reviewing. the real problem i believe is the coredev system itself, reviewers are not responsible for reviewing a pr, and big prs usually will potentially have more issues and need more time to check, but with the same amount of time, we can revoew many other smaller prs. its a system issue, not a single one of us can change it, but adapt it.

[Jim8y]

so i highly recommand you to split it. or i can do it for you without taking your bonus.

[cschuchardt88]

I could see this being a problem. If we have deadlines. But we don't. Its only 32 files, many small. It should be the job of the tester, to test it and use it for some time, to make sure its in working order. Also the job of the developer doing the PR to do the testing. Most PR's are un-tested before merge. So I can understand your point of view. Just know this I test and test my code before I make PR. I am over compulsive about style, code functionality and code design.

[lingyido]

Please take all your time for this one. I see no good reason for updating new features for levelDB which is an essential modules. I personally disagree these great changes.

[cschuchardt88]

Please take all your time for this one. I see no good reason for updating new features for levelDB which is an essential modules. I personally disagree these great changes.

Its more stable and done properly in dotnet for the GC and other things.

[cschuchardt88]

No Performance Increase, Stayed the same

[cschuchardt88]

Check Simplified PR #3414 with minimal changes