can someone help to create version 0.5.2?

[gzhhong]

Hello the team here, can someone give help to create the version 0.5.2 to include the latest changes ? I plan to use the API like EnqueueUniqueInByKey. Thanks a lot !

[gzhhong]

Hello, is the project still active? why there is no upgrading and support anymore?

[skplunkerin]

Same question for me... v0.5.1 doesn't have the latest changes, which really sucks as I'm also needing to use EnqueueUniqueInByKey()

[skplunkerin]

For future users needing this, here's how I got it to work:

1. I updated my go.mod file have the latest master commit hash, instead of the v0.5.1, ie:

   github.com/gocraft/work 5959e69ad211c5ca37ffdf3ede02e35a5ae41d98
   

2. I then ran go mod tidy to confirm it worked, and it changed the git hash to:

   github.com/gocraft/work v0.5.2-0.20200429214246-5959e69ad211
   

I don't know how/why go mod is smart enough to change this to the missing v0.5.2 version, but I'm happy it worked.

I think you could technically do github.com/gocraft/work master, but then that will probably grab unexpected changes for when/if anything new commits to master (which I don't want any unexpected surprises).

[CodechCFA]

Looks like the maintainers are trying to replace this with https://github.com/taylorchu/work, which I think is a mistake because there are no plans to replicate the Web UI in that project the same way its done here. I believe that makes this current version far superior that the new version they are building.

[skplunkerin]

Bummer. I'm in the process of looking for an alternative since this project is super dead... I've found problems with the EnqueueUniqueInByKey() not working as it should.

[gzhhong]

@skplunkerin , have you make the EnqueueUniqueInByKey() work?

[skplunkerin]

@skplunkerin , have you make the EnqueueUniqueInByKey() work?

Yep, see my comments here on how to install the master commit hash, which will allow you to use EnqueueUniqueInByKey(). Just know that it doesn't work exactly how the README says it should work (in particular, you can't use the same key until 24 hours later, even if the item gets consumed... There's no built in way to clear it out or pick a custom TTL; whereas the README says it's supposed to be cleared out after consumption so the key can be used again).

[gzhhong]

@skplunkerin , thanks a lot for the information. My purpose is to enqueue a unique job, and before the job is executed, if there are any changes on the job parameters, I can re-enqueue the job with new parameters, by its unique key (to overwrite the job parameters). If the key can't be used in 24 hours, then the EnqueueUniqueInByKey is just a bug implementation. Do you have any other suggestion for my problem?

[skplunkerin]

@gzhhong correct, basically EnqueueUniqueInByKey doesn't work the way it should work. I think what's needed is to add you're own Redis logic layer on-top of gocraft/work that you can use to delete the key, so that you can re-use the key within the 24 hour TTL. Either that, or try to dig into gocraft/work to fix this issue (or add configurability for setting a custom TTL/whether a unique key should be deleted after consumed). It's probably faster to just build your own layer on-top of this, but I could be wrong; this is the direction I'm considering on going.

[gzhhong]

@skplunkerin , many thanks for the help!