I’m sorry, didn’t mean anything offending. The dependency change is completely fine, I was mainly worried about docs.
So the main documentation will stay at ecto, right? This was not clear to me and my main concern which I expressed in this grumpy way.
Just to clarify, what you said was not offending. 
It is totally fine for you to voice your concerns.
However, it doesn’t change it is disheartening. Ecto v3.0 was a long term effort, there are so many good things coming with it, but everybody fixates exclusively on this one thing… and it is tiring. It is the kind of stuff that makes you stop and think: why am I doing all of this work anyway?
Yes, docs will stay in Ecto. The ecto_sql is more about moving all adapter implementations out of Ecto. If you want to use MSSQL with Ecto, you need to bring the adapter, right? So now you need to do that for PG/MySQL too.
EDIT: I won’t be getting notifications from this thread. If somebody has implementation concerns about any of the breaking changes and they want to make sure it will be seen, please move the discussion to the issues tracker. Thanks.
I think it was worse with the formatter 
I hate breaking changes. Ecto 1 -> 2 was a big headache for me. I guess I am totally going to use pure sql or :mnesia. Although evolving to a major piece of tool requires some breaking changes, but I think using backward compatible library in a mission critical production is a necessity.
You are welcome to use whatever you like, but this “breaking change” boils down to:
-{:ecto, "~> 2.2"}
+{:ecto_sql, "~> 3.0"}
Unless you are using the old calendar types which I believe have emitted a deprecation warning since 2.1
A list of breaking changes is available at https://github.com/elixir-ecto/ecto/blob/97a6350ab223f0dff95bf609b75e1b960214d82e/CHANGELOG.md#backwards-incompatible-changes
To compensate this I would like to say that I’m in another group which (at least for now) is fixating exclusively on others changes (mentioned in query improvements) such as: Better join composition with named bindings and Database prefixes and index hints which in some cases would be really powerful change. Hope your heart is now soothed a bit. 
:
btw. Are named bindings finished already? I have tried them one time and had an compilation error when trying them with few inner joins, so I used old way thinking that it’s not yet finished …
Do you have any plans for first release candidate? Some changes are really important, so this time I could give some feedback really soon. There is really big chance to use latest version in our prod environment. 
Eh, (almost) everybody hates breaking changes.
Ecto 1 to Ecto 2 was definitely painful because it provided an overhaul on how to structure your code. But the breaking changes in Ecto 3 were kept to a minimum and a lot of work was done for such. As a maintainer, it would be much easier for us to just break the code.
If you feel going through a handful of breaking changes in Ecto 3 is more work than writing SQL queries by hand, coming up with your own rules to structure code and probably writing your own data management code, then by all means roll your own.
Otherwise, if you want your tools to get better, faster, more resilient, etc, then you need to accept some breaking changes will come along the way. You can either get involved in the project to make sure those changes are kept to a minimum or hope the maintainers were kind enough to do the work for you.
It should be complete now. If you find any bug, feel free to report them!
It was meant to go be out this week but since Phoenix released a RC, we decided to postpone for next week. For all purposes, it should be ready. @wojtekmach has even done a PR to update Hex to Ecto 3.0 and everything seems to look good.
We will definitely appreciate the feedback from people trying it out! 
Well, Thats an awesome news Jose. I think you changed the way live nowadays not because of elixir, but cause of the way you push everything forward.
Thanks and I’m waiting for E3 release.
oh, in such case I have tested this code again
Unfortunately it’s still does throwing BadMapError. I have reported it just now:
Excellent! I’m sure that we will use it soon in prod then!
To me it made sense because…
Could this also mean that in the future we might see…
etc?
Progress trumps minor (even major) breaking changes any day of the week for me 
I think many people have come to Elixir and Phoenix in pursuit of something akin to perfection; a better way, and we love that José and Chris and the core teams of the various projects in the community (and even going back to Erlang with Robert, Joe and Mike) had a relentless focus on doing what they felt would represent the cutting edge in an as accessible as possible way.
Although Elixir and Phoenix (and projects like Nerves and Scenic) will I’m sure mature very nicely (you could argue most already have), I can’t ever see them stagnating, because it seems to be in the blood of those involved to keep introspecting and evolving 
Part 2 is up
That’s some really great news, many quality of life improvements. Congrats, great work!
Great work! I welcome these changes. The ecto schema capabilities are powerful on their own and it’s great to see it as a standalone library.
That’s part two of the query improvements article (not the breaking changes article), and you haven’t linked part one.
A better title for the thread might be “A sneak peek at Ecto 3.0”, the title of this series of blog posts.
Thank you for your unending hard work and dedication. It’s sad to see some throw away comments cut you like that. We, at Clever Bunny appreciate all the time and effort you put in not just in code, but in guiding the teams. Looking forward to trying out E3 soon. I’m sure we’ll manage the breaking change somehow. Warm regards
I could not agree more. We, at Kantox also appreciate this and are very thankful.
© Copyright Elixir Forum | Terms | Privacy & Cookies
