If you were about to start a medium-sized #PHP project, what would you choose as an #ORM, and why? It should be something stable and well maintained. If the business takes off, then there should be no need to replace that layer.
Caveat: imagine that Doctrine and Eloquent haven't been invented yet.
@zimzat yeah, on the surface level things seem to be attractive, but as you go further and deeper, facepalms emerge. Some dbal & a custom data mapper will probably be the start.
I use Doctrine on my day-to-day work, and have used Eloquent before. Eloquent I liked up to some point, but can't say that for Doctrine. I wish I had more time to build something like Eloquent but with less magic and bloat (simple to use but not trying to do everything imaginable)
@oliver I mean.. the way you put it, the data mapper is only convenience probably. I think valinor supports stuff like nested levels that ocramius/GeneratedHydrator doesn't for example. Not sure 100% for either.
Personally, I would not consider writing my own data mapper, just for the sake of not losing time with the project.
Recently, I favour the notion of "first version is probably throw-away code" and just try to make it work. It all depends on what level you design things, I guess..
Switched from #docker desktop to #orbstack last week, so far so good. Everything runs way faster, and the effect on battery life is noticeable as well. The only thing I had to do exra was docker-compose up --force-recreate since a network has been missing.
@ilijastuden ova 😄 donedavno je stajala u šteku sa još nekim. Prije par dana uzmemo ove police, krene redanje knjiga i kad sam vidio ovu... to nije moja knjiga 🤦🏼♂️
This month long code freeze is killing me. #Phan reported several thousands of errors and it's a real struggle to organise pull requests in any meaningful way while everything is on hold until January 🥶
Air #pollution is so bad tonight in Sarajevo, Bosnia and Herzegovina, that my phone warned me that its lens is dirty when I tried to snap a photo of it.
One of the annoyances found in the #PHP codebase I'm currently busy with is finding many traits that are used in one single class. Those traits have literally zero other places they could be used at, so... why? Just because someone else did it, you don't have to the same thing. Also, don't do that if you think it just may be needed in the future. Do it only if that's really, really needed now.
@oliver the answer is oftern - bad design. I'm in a similar project, where traits are used to organize common functionality AND to organize different functionality within a single class. The very description shows the issue, but there is some people issue usually to explain why should we go full OOP.
I also click on the "premature optimization"- people don't get it that keeping your impact at any point to the minimum is what business will benefit the most.
This weekend was the one when a moderately important 1.2TB #MySQL table gets locked up because its primary key reached its max unsigned int value, and no more inserts could be performed 🥶
Let's see how many versions of #Docker I need to go back to, in order to up my containers under 5s again. This last upgrade to 4.25.2 is unbearable, it takes ~3 minutes for something that used to be a couple of seconds (no builds etc).
Wondering if that's something specific to my setup or the progressive degradation is noticeable for others as well?
@alexdeathway It's spinning up 10 containers... it was like that before, and gradually got worse and worse, while literally nothing changed on the containers' side.
I initially thought that maybe running the 1st time after an upgrade is doing something under the hood, and that subsequent runs won't be so slow. I was wrong, it was that slow every time. Thankfully I don't need anything from the newer versions, going to ride this version for as long as possible :D
A bit of a rant about some #PHP composer packages.
It's such a burden do deal with those that bump the PHP runtime requirement up to ^8.0, and also drop the one for 7.x in the same release, with no actual changes that would really make the package depend on 8+. Literally zero buffer for the transitional period which would allow projects to sit on 2 chairs a bit.
What this means in reality is that the feature branch to bump the project to the next #PHP version grows with no real need or benefit in such cases. Those packages need to sit in a feature branch, growing the diff and congnitive load for everyone involved.
It's not always the case with 7->8 bumps only, I've seen many bump the requirement to e.g. 7.4 and drop the 7.1 in the same release... with zero 7.4-specific features used in it.
@oliver Although I only make these changes with major versions, the 7.x branches of PHP have long since been EOL. 8.0 is only in security update stage now and only for the next 3 months.
Also well aware of the issues of, and companies in particular being extremely slow to upgrade, but maybe the package maintainers just want to keep their packages up to date in regards to what they support. Supporting EOL versions only contributes to the issue of old versions of PHP hanging around.