ORM for Model querying

[hotwer]

I really would like to know...
Why there is no ORM such as Doctrine or Eloquent?
I really don't see any reason why you guys don't implement it.

Querying would stop relying so much on having to be in such specific databases, and also it would remove any kind of complications while editing any models.

Is there a reason for it? It also would turn it really easy to create any new modules for opencart (easy development, as you guys should know). Also I don't think it would involve into updating it as a major update, just a minor one. The return of data would remain the same, and the idea is just to remain the DB class for the modules versions.

[danielkerr]

because ORM is very limiting from actually writing raw SQL.

it also means having to lean another API (which might not exist in another 10 years as many frameworks come and go) for no other reason than encapsulating SQL when knowing SQL is more beneficial.

[hotwer]

Almost all querys made are simple.
And the idea is to REMOVE the raws queries. Today, opencart is not flexible enough to accept SQL Server and such... With ORM, you would remove this independancy.

Also, your 'problem' that is going to 'lean' on another API is going against tides IMHO. If you want to upgrade your application, you will always have to learn more and more. It's irrelevant, also I think it's bad a thinking that you're going to use te same technology for 10 years.

A good app is modular enough that you can upgrade it as the technology increases. Not the contrary. I really don't know what kind of standards you're following but thei're not beign the best in my opinion

[hermans]

I think with ORM its still able to make raw query.
I get some problem when customize opencart to be larger application, with current sql this is really spend many time. i suggest if you interest to use simple ORM like "idiorm", i have been used this ORM for many work and really help to save time and work.

[hotwer]

Daniel, I suggest you to reopen this issue and let the community discuss a bit if whether or not is a good idea to use a ORM or not...

Otherwise it wouldn't have be a good idea to put your repo on git if the idea is to just don't accept any ideas to improve the project (use bitbucket if it's not what you want).

Also, in my point of view, today's opencart has a lot of problems with his controllers and such (poor code reusing, and stuff) I think it'd be a good idea to discuss about it as well.

Right know I use opencart in my projects as a starter... And don't get me wrong it's a very powerful tool as and e-commerce shop. But it's design doesn't helps much when developing new modules and stuff and even also custom tweaks and fixes/changes.

We have a good way to go, but a lot to improve.

[danielkerr]

@hotwer I will do what I want with my project! I don't work for the community!

I spent enough time with DB ORM's to know they are pretty useless.

[hotwer]

@danielkerr , I'm not saying you need to do what to community wants to, I'm just saying that the community has a lot to help in with your projects. I can, for sure, say that any project really open can be developed fast AND be a good project with pretty almost no flaws.

There are a lot of researches saying that a group of people, organized as such (and is an enviroment provided but github supports it).

It's up to your follolw this tip I'm giving or not but closing your project on github won't help you in anything.

And about the ORM, you should look at some kind of ones I really, like such as Eloquent and Doctrine (this not much, but it support transactions and has some advanced features for good performance).

[sarrala]

@hotwer Enough support for ORM (+few other improvements) and prove it useful and it will get in, other divided foss projects have shown it already. It would however require full support from community and a lot of hard work.

If you'll just fork this out and really really make it better, gather support from community and keep compatibility then there's no reason why people who found it better for development (or any other reason) will happily follow leader who wont shout "I will do what I want with my project! I don't work for the community!" but instead looks forward hearing community's voice.
Maybe something like http://opencartcommunityedition.com/ but rolling release.

Coding is not that hard, leading is, especially when you're the one who need to keep ~50/mo issues clean, oversee commits/pr's, make sure that tests won't fail afterwards and so on... so, sometimes even good leaders have their bad moments. Think about it first if you're going to be one who's planning to lead competing project.

That said, I can't give my opinion about ORM as I've not used those that much. (was this issue about leadership or ORM?)

[scottw-finao]

re: it also means having to lean another api (which might not exist in another 10 years....

lol - more like opencart won't exist in another 10 years because it seeks to create it's own proprietary everything, ignores new standards and methodologies and writing for it reminds me of writing phpcode in 2002

propel orm was started for symfony in 2003 (20 years ago)
active record was conceived in 2003 (20 years ago)
doctrine orm was concieved in 2006 and released in 2008 (15 years ago)
redbean orm first appeared on github in 2009 (14 years ago)
eloquent was added to laravel 4 in 2013 (10 years ago)

(As someone who had to learn zend for work at a company, I can relate to libraries that don't exist anymore. Yet it is important to note that the reason zend went the way of the dodo isn't because of anything zend did. It's because the functionality Zend framework provided was pretty much incorporated into PDO in php itself)

[scottw-finao]

ORM pros and cons:

cons:

• you are dependent on the third party developers and the platform remaining in existence and updating their code base
• any changes to core behaviors of the ORM will require you to update your code
• orms add some overhead to code execution times

pros:

• the orm layer has a uniform 'syntax' regardless of what database it is connected too. e.g. there is no need to have one function for saving to mysql, another for mariadb, yet another for postgresql, another for mssql, and one more for oracle.
• changes in the base functionality of a rdbm engine can usually be adapted too by the ORM without changing the ORM syntax. i.e. the database syntax can change and your code will still work once the ORM is updated by the maintainers.
• utilization of some new database such as amazon RDS only needs the ORM developer to add additional code to support it. your code only needs minor changes to point to the new data source. (and when things like RDS support emulation of other engines like mysql, you can modify the connection yourself without waiting for the maintainers to do so)
• while there is additional overhead to use the ORM functionality, most ORMs are going to focus on reducing that overhead themselves, allowing you to leave performance issues up to the maintainers.
• any good ORM can make difficult syntax for complex queries easier to code-for
• any good ORM will include sanitization of queries in their standard usage
• any good ORM will handle formatting special characters
• any good ORM will spit out and convert to and from multiple data formats including (optional) mapping to use key/value aliases for column names and respective values - making hydrating model properties very easy.
• any good ORM is going to be consistent with best-practices for the language on which it is built. (e.g. for php it will use composer for installation/updating, will be PSR compliant, can plug into anything that uses composer/packagist and standard autoloading with PSR namespaces, etc.)