search

mvniekerk / tokio-cron-scheduler

Schedule tasks on Tokio using cron-like annotation
Apache License 2.0
499 stars 61 forks source link

How about do not depend on prost if not enable nats_storage or postgres_storage? #20

Closed deftsp closed 2 years ago

deftsp commented 2 years ago

I'm using v0.5, it works very fine thanks! v0.6.x depend on prost, even not enable the nats_storage or postgres_storage. It's too heavy for a small project.

mvniekerk commented 2 years ago

Hi @deftsp Thank you for the bug report. The Prost generation of structs are giving a base to sequence / store the metadata and notification data of the jobs, allowing a generic way of handling and scheduling tasks regardless of the backing data store. In terms of code base, v0.5 vs v0.6 is thus totally divergent. Only the user facing API stayed the same.

I agree - having Prost generation happening on initial compile could be seem as hard handed. But, the v0.6 code simplified and ordened things a lot. The amount of lines of code is v0.6 (without Postgres/Nats) = 3647 v0.5 sits at 1313. With the above I have to agree, the code base is bigger. But the generated Prost file is only 130 lines of code, code you still need to put back afterwards. There's also a lot of lock contention issues on the 0.5 design.

In short - I don't think I can help you with this. Sorry.

BrettMayson commented 2 years ago

The inclusion of prost is also preventing me from using this project

mvniekerk commented 2 years ago

@BrettMayson , @deftsp Question - what part of it is preventing you from using this?

deftsp commented 2 years ago

I'm still using v0.5.0 for my project. I do not want to increase the dozens of dependencies introduced by post. The API of v0.6x is pretty, I like it. I might find time to create a PR with a feature which able to make prost optional

mvniekerk commented 2 years ago

Ok - in terms of design, I'm using prost to generate bytes to put on the Metadata and Notification stores. If you want to remove Prost then you'll need to provide your own to/from bytes implementations. Maybe there is a simpler way around this

deftsp commented 2 years ago

I mean the design should allow the scheduler just run in memory unless the feature(like postgres_storage) has been selected. In that case, there's no need for the to/from bytes implementations.

BrettMayson commented 2 years ago

I also just want an in memory solution right now and have been testing with 0.5. When I tried 0.6, the VM shot up to 100% CPU usage and I got disconnected from SSH, had to restart it and downgrade to 0.5 before I could compile

mvniekerk commented 2 years ago

Hi @deftsp and @BrettMayson Check out v0.7.0 - it makes Prost optional.