[sintakonte]

The thing with an ORM is - it helps you structure your data (and i'm not talking about doctrine, propel or any other siwss army knifed constructions)

it doesn't really depend on which database you use.
If you have relations from one data to another, you should have an automated way to structure those data, because it really helps if you don't have to care about that.

In my opinion, thats what a framework should stand for  - because it has the duty to support excactly those tasks.

E.g. it was a nightmare for us to develop applications in CI before we developed our "own" simple ORM (loosely based on Laravels approach).
You can see an example how such a model looks like below:

PHP Code:

class Book_model extends CrudDb_Model
{
    public $strDbTable = 'books';
    public $strDbTableObject = 'Book_Object';

    public function __construct() {
        parent::__construct();
        $this->addConnections([
            'author' => Relations_Factory::One(
                'author',
                'resources/Author_model',
                [
                    'author_id' => 'id'
                ]
            ),
            'chapter' => Relations_Factory::Many(
                'chapter',
                'resources/Chapter_model',
                [
                    'id' => 'book_id'
                ]
            ),
        ]);
    }
} 


And thats it - defining Relations how certain data are standing to each other isn't really an opinion based concept rather than based on facts (in our case a book has chapters and an author). So i'm really curious, why you guys are so eager to avoid exactly this topic at all costs. 

Because exactly this concept would help so much others (i don't know how many SO posts i've seen where people actually got lost because of the frameworks inability to deliver this task...)

[ciadmin]

See https://en.wikipedia.org/wiki/Object-relational_mapping

One could argue that we *do* what an ORM is meant to do.

The problem arises in what else developers expect an "ORM" to do, and there is no single ORM that would keep all the developers happy. You suggest that managing relationships would suffice, but others insist that their ORM should generate scaffolding, or should have container-based persistence or entity-based persistence.

[sintakonte]

to be honest i don't really care if this (possible) solution is called ORM or not - but in my opinion we all handle data - and we all do it in different ways - which is probably good so - but all data have one common - they need to be structured.

And thats what brought us to the decision to make something which actually does this - because if you review your controller/model codes you'll see you do repetitive/redundant tasks overall your application and they all do the same - structure data

And if you inspect this closer - you'll see the amount of effort you did in order to structure those data - but in reality it can be abstracted and you (as a developer) can give those responsibility away, because its always the same.
(funny fact: one of the most controverse things in our company was actually to implement this, because 90% of our developers felt somehow lost -2 months later, everybody acknowledged that this is actually really useful)

So to come back to this topic, to structure data isn't opinionated, but a need - and i don't really understand, why some lead developer want to avoid exact this topic.

That said, i don't think you've to actually use it rather than you can use it, it always should be optional. But in my opinion it's mandatory in modern development, that a framework should provide that functionality - and it really doesn't matter whether your source is a CSV File or a Database, the underlying Mappingsystem should be able to handle both...

The problem arises in what else developers expect an "ORM" to do, and there is no single ORM that would keep all the developers happy. You suggest that managing relationships would suffice, but others insist that their ORM should generate scaffolding, or should have container-based persistence or entity-based persistence.

Yeah - i heard and read this argumentation a lot - but for me, this isn't an argumentation at all - rather than a responsibility shift, which isn't necessary - because you as the Framework Host and Owner take this decision after all. And thats the reason why i wrote this, because if i ignore your argumentation (by any means - no offense...), i'm able to discuss this based on the facts i pictured above, and thats't it - just to start a discussion, how to structure data on an automated way (it really doesn't matter if you call this ORM or not).

[Pertti]

It'll get very tricky the second you step out of small to medium sized projects.

Sometimes the best solution from user point of view is to pre-calculate and store cached data based on weird rules, or fetch some data only when necessary.

But I also agree that most of the times you are better off having nicely (for lack of better descriptive word) structured database, when it comes to relations, than trying to have quick solutions - most of the time projects grow in complexity and painting yourself in the corner for quick early wins doesn't help.

[sintakonte]

lazy loading is mandatory in this regards - and for larger growing projects is this approach perfect, i took a look right now in one of our  projects - currently we've 254 resource Models (each model represents one DbTable), 55 custom Models and 140 Controllers and nearly all of them have an average loading time below 200-250ms.

I know this is a hardwork - we needed ~4-5 months (2 guys) in order to develop such a functionality.
I came up with this topic  because history told us to change something and this helped a lot.
It was necessary, because it helps to reduce redundancy, avoid a ton of mistakes and helps to read the code better.

[ciadmin]

@sintakonte What you are saying makes a lot more sense than most of the "ORM want" posts I have seen. I suggest you propose/describe an interface that would suit your perspective, for community discussion. If we can come up with a practical & generally acceptable way of tackling this, it could make its way into a future version of the framework.

[skunkbad]

So i'm really curious, why you guys are so eager to avoid exactly this topic at all costs.

most importantly for me, I don't want to use a framework that tells me how to work. Especially in this day when we can pull in Composer packages for almost anything, I don't like a framework that assumes I should work a specific way.

Take Lumen for example. Lumen is a trimmed down Laravel that I like more than Laravel, but it assumes things that make it a pain in the rear to use for anything except for an API. "Well it was built for APIs" you might say ... and that's where I say you'd be assuming too much.

I think you are on to something though, but it belongs in a Composer package. If you're even partially right about ORM, then if you make a package that people can pull in and use in their applications, people will be doing things your way and you can have a sense of accomplishment and satisfaction in knowing that you've contributed to open source.

[InsiteFX]

Beside's CI should keep it's position of being fast and simple to use.

Anyone can add on their own ORM etc; But please keep CI small and fast.

[php_rocs]

I second what InsiteFX says. 100%. Keep it lean and mean.

[kilishan]

@ sintakonte What functionality does your current solution provide? And any chance you're able to open source that for a kick start to the project?

I, personally wouldn't be opposed to a simple solution that doesn't try to do everything that Eloquent/Doctrine/whatever does. I've started playing with such a project in my spare time, but have not gotten very far because it's at the bottom of my list of priorities for this project currently. If we did this, and I'm not saying we would by any stretch, it would be a separate repo that could be included through Composer.