Is it? Is it not? “ORM is an anti-pattern” | Seldo.Com Blog

If you are into whether you’re going to use ORM in your next project or not, you’ll appreciate the thoughts about why and when ORM can be bad for the application. First its design flaws are shown and then alternatives are given. Too many queries, the need to break the abstraction by using raw queries, how bad it can be in the long term when it’s too late and many more:

ORM is an anti-pattern | Seldo.Com Blog.

I personally like ORM, defining the relations properly and then having the powerful code coming from this abstraction. I am on my way to use ORM in a big project too. I also know and use SQL a lot for example in data mappers. I think sometimes it may be better to create a custom in-house ORM for a project though this may require constant changes to it when adding new features. I also think that every query produced by the ORM should be checked before going in production and also using a monitoring tool for your application in prod and testing your application by overloading it in a dev environment is good.

Defining relationships among database tables with Eloquent @ blog.andreasartori.me

One very clever article showing all types of complicated relations that you may stumble upon in your job.

The author shows in a very clean way how to create such migrations, seeds and models.

Check out how morphs(), morphTo(), morphToMany(), morphedByMany and withPivot() are used.

Read it a couple of times, test it with all possible databases Laravel supports and see the differences, check the structure created: tables, data, foreign keys. Add, delete records and see what happens inside the database. Try creating your own app using these functions to get even more clear picture.

Laravel, Eloquent, polymorphism, one-to-many, many-to-many and polymorphic many-to-many relationships:

Defining relationships among database tables with Eloquent.

Docker container with broken Mysql database. Lesson learned. Backup often. Backup your DB or at least the container.

I’ve been updating lxc-docker every time a new version is suggested by my Linux OS. While the apt-get install lxc-docker was working it stops and starts again with the new Docker version. Usually nothing happens with the containers being forced stop and started that way but today I’ve had a broken Mysql DB for this WordPress installation and couldn’t restore it from its data directory no matter what I’ve tried. Because I didn’t want to loose more time I decided I can restore previous commits to the same image that container is running from.

I’ve found the docker history imagename command and tried it. I’ve added a couple of commits to this image and I’ve had a couple of lines with the history commands. I’ve picked the commit before the broken state and ran the wordpress container the same way I am running it with the :latest tag but this time used the commit ID. It ran well and I’ve made a commit from it to its image. Stopped and removed the wordpress container and ran it with the usual command using the latest imagename command this time and now it’s running well.

Now I know that when I am going to stop the images and update the Docker executable I must backup the databases, files and commit the latest state of the containers (not much by the rules because the container should be able to be rebuilt at any time keeping the data outside the container).