Todo: Support ecto 3 and ecto_sql about ecto_job HOT 10 CLOSED

@mmartinson any luck with this?

from ecto_job.

@anthonator I had a try at supporting ecto 3.0 in the ecto3 branch

The things I ran into:

• The migrations use utc_datetime which no longer allows supplying a factional component. So we need to decide which timestamp type to use: utc_datetime or utc_datetime_usec and/or make it configurable somehow (related #19).

• Ecto 3.0 migrations didn't work when the migration scripts were stored in the test/support directory instead of priv. I think this is fixed in Ecto now (elixir-ecto/ecto_sql#33)

• Repo.update_all(..., returning: true) is deprecated, so had to change some queries to include a select: clause.

It might also be a good time to review #18 and decide if we want to allow the ID of job tables to be configurable.

from ecto_job.

Hi. So I created a fork to make it work with Ecto 3. Regarding bullet point 1, I just went with utc_datetime_usec because I had no idea if usec precision was needed or a thing. Regarding 2 I just moved around certain files to go in their default locations. For 3 I just ignored the warnings.

You'll also notice that I just reformatted the project and reorganized the config files. With all that said the tests pass. Haven't gotten around to actually using this in a toy app so I have no idea if that's even meaningful. All I know is that it compiles, it can run migrations, and tests pass.

Would love to see the project updated to work with ecto 3 so I can just drop it in as a dependency.

https://github.com/baron/ecto_job

from ecto_job.

@mbuhot I checked out your branch.

I would be in favour of keeping usec precision instead of truncating, at least as a supported option. Since ecto 3 is now ditching microseconds by default I think we should follow suit. As a first pass, I like the approach of using the MyApp.Repo config for determining all timestamp types, possibly with override as suggested in the last point in #19.

I'm curious what a migration path would look like for existing applications here. It seems any that had already generated migrations with ecto 2 would retain usec info in the db, and we could suggest in upgrade docs for the next release that usecs need to be configured in they want to keep them?

Is the migration issue you mention the reason you used ecto_sql master?

If you have a fix for the update_all deprecation, do you want to merge it in advance to separate it from the ecto update so it's there when we need it, or do it depend on ecto 3 features?

@baron those test fixes you did could be useful if we want to test both the truncated and non-trucated paths based on config.

from ecto_job.

@mmartinson I think those timestamps should be consolidated into several variables to be reused throughout the tests (I only hunted them down for a quick fix). I agree with following Ecto 3 in ditching microseconds unless there are some compelling use cases for that level of precision for background jobs.

@mbuhot I couldn't get things to work with ecto stuff like repo.ex in non-standard locations. Might be easier to just follow the defaults.

from ecto_job.

mbuhot I couldn't get things to work with ecto stuff like repo.ex in non-standard locations. Might be easier to just follow the defaults.

@baron Can you clarify? In our case we have test-only Repo and migrations that cant go in priv Since they are not intended to be used by package consumers.

from ecto_job.

Hi, just wondering if this is likely to get updated soon? Are there any other blockers? Is the 3.0 branch likely to get merged and released? Anything I can do to help?

from ecto_job.

@seangeo one small change that we can merge immediately is to replace all the usages of update_all(..., returning: true) with tye equivalent select clause in the queryable.

from ecto_job.

@mbuhot sorry, I'm not sure what you mean here? select isn't supported in an update_all until 3.0, so we can't merge that until the Ecto dependency has been updated to 3.0 right?

from ecto_job.

@seangeo sorry about that. I've created PR #28 that should bring ecto3 support without changes to the ecto_job API.

If you have an application to test it with, please give it a try and report back any issues. Thanks!

from ecto_job.