New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Plan for v2.0.0 #106
Comments
Good initiative Moritz! I'll help you as much as i can. From my nohm experience, here my feebacks :
Here my recommandations about the evolution of Nohm, some features that may bring this framework to the next level :
Hope this remarks are relevants to you. Regards, Edit: ps: is this possible to have rights to edit(labels)/close others issues? |
I have updated my comment to link issues/questions, correct grammar/typo, and add somes elements. |
I agree on Error handling. The current way is not good. I'm very on the fence about any kind of access control. In my mind this is something better handled by either a seperate module/layer or the application itself. The pub/sub thing I don't quite understand. What's the legitimate upside of that compared to subscribing to it on the model and just checking if you're interested in the update with 1 if clause? If it's performance, then I think this would be something for a version 1.1 and should be researched/benchmarked as a first step of discussion. Maybe you could create a seperate issue for this? Instance on validator should already be there in Geodata to me would be something for a version 1.1 or 1.2. Definitely interested in this though. Transaction safety: Will at least be explored for a version 1.0. I would take this on as a should, not a must and then a must for a version 1.1. What do you mean regarding "Backup rules"? Admin interface frontend is currently written using Marionette and talks to a json API that is REST-ish. Documentation: Agreed. I personally currently prefer jsdoc with something like docstrap. There already are jsdoc style comments for almost everything, so it would make sense here as well. Current jsdoc output is... not ideal though. Benchmarks/performance: I still don't really know how to do meaningful ORM benchmarks. But I guess we can try?! Regarding TTL: My concerns still remain. I'd put this under "to be researched" as well. |
I see whee the confusion about |
Awesome. My bad for #94, havent noticed this update(i will review the code to understand correctly the execution flow). Also, my backup statement was pointeless & off-topic, this is specified at runtime in the configuration file, not the redis client. About pub/sub, i added it to my code at init phase, in a function with multiple subscribe to multiple model, and differents handler than check what has changed. I just cant find it readable at all, it's maybe just a personal matter on how i achieved/dispatched this. Documentation: Great, docco was just the first thing i found on google. I have not really remarks about the choice (as long as it is more readable). Just one point : imho docs should be versionned in this repo. Benchmarks/performance: Let's just start with something simple. As a draft, let's make a tool that each user can send share the result by specifying their cpu/mem (based on https://www.npmjs.com/package/benchmark ?) :
Ps: i'll go off on hollyday ten days this Thurday, i will be able to read message, but wont be able to work during this period. |
I think it should be nicer with |
@katopz Actually, you're free to use |
I'm writing a benchmark for CRUD nohm, and I came across a redis client lib benchmark. Actually there is 3 mains nodejs redis-client : node-redis (used by Nohm), io-redis, Thunk (wasnt aware of it) io-redis and thunk seems more featured than node-redis.Thunk redis, got specifically my attention :
Could it be a good idea to move from node-redis (which looks less maintened than the other 2) to thunk ? |
Benchmark done for CRUD model & link : #110 |
Transactions would be great! |
Typescriptification and Promisification is done. There are still more things that could be done for the typing. Created #118 for that. I'll publish this as 1.0.0-alpha.1 If anyone is interested in migrating something to alpha.1 in a test environment, I'd be happy to assist. Currently there is no real guide for changes done in v1, except a small list I tried to keep in v1_changes.md. The best place to start might be looking at the example/rest-server, since that is finally up-to-date again. |
TS+Promise version is published as nohm@1.0.0-alpha.1 and nohm@alpha |
To prevent breaking dependent packages/apps, I think this will have to be v2.0.0 and I'll tag the current 0.9.8 as v1.0.0 before releasing v2.0.0. Because v0.x.x is not defined as a stable API according to semver. nohm should have been at v1.0.0 a long time ago, but I just never did the jump. Since this is only a naming thing, I don't think it'll cause many problems. |
For the reasoning behind the v1 to v2 change see #106 (comment)
2.0.0-alpha.6 published as tag alpha |
2.0.0-alpha.7 published as tag alpha |
where's the doc for v2.0.0 .... |
Not written yet. But you're welcome to help. |
edit: fixed now, see comment below this one. @fatfatson https://github.com/maritz/nohm/blob/gh-pages-v2/index.md is the new documentation. As long as v2 is not done it will not be 100% though and the styling on that page is obviously broken and can only be fixed by moving it to the proper gh-pages branch. There is however a guide on (hopefully) all breaking changes in the HISTORY.md Any feedback or documentation bugs is very welcome. |
Nevermind, I published it on https://maritz.github.io/nohm/index_v2.html now, so the styling and formatting is fixed. |
I have decided to leave out custom validation files in v2.0 and instead move the re-introduction of them to either 2.1 or 2.2, not sure yet. (#132) It's a feature I'm not using myself and that is actually kinda problematic in some ways. In addition custom logging has been removed from the plan. Instead documentation should just point out that you can monkey-patch nohm.logError with your own function. With those things in mind and the old v0.9 finally being pushed to v1 I will probably make proper v2.0.0 release in the next few days. The original plan was (now obviously) too ambitious for v2 and lots of things have been moved or just cancelled. However the improvements in code quality and usability have been very well worth it for me personally. |
Will release v2.0.0-alpha.12 as v2.0.0 and tag it as stable on Sunday if nothing else pops up. |
Some things popped up. Let's try v2.0.0-alpha.13 this weekend. One thing I only realized today: when doing For some reason I thought npm would install stable by default, not latest. That is definitely not what I intended. Sorry for any inconvenience this may have caused. But at this point I'm not gonna re-tag v1 to latest, because v2 should be ready for release now. |
Published as v2.0.0 and marked as latest and stable. API docs have been re-introduced at https://maritz.github.io/nohm/api/index.html |
congratulations! |
At long last I am planning to work on a v2.0.0. My current goal is to have this done this fall.
Must haves:
improving logger behaviour (currently console.log)(see point directly below)Should haves:
Transaction safety⏬ Does nohm automatic manage dependencies with transactions(redis-multi)? #64use mocha/jest/other instead of nodeunit⏬ Move to other testing framework #116Some kind of migration helper when you change your model schemas⏬ What is the preferred way of doing migrations/schema changes? #33Benchmarks⏬ Benchmark #110Research and categorize:
Geodata⏬Lua scripting⏬ Using Lua? #93Discussion points:
While this is going on I also want to have the admin interface in a state that is at least read-only complete for v2.0.0.
Discussion & feedback & ideas are welcome.
This was previously labeled as v1.0.0 but has now been changed to v2.0.0 to keep compatibility for dependents.
The text was updated successfully, but these errors were encountered: