4 years old mysql doesn't sound unreasonable.

Mysql 5.6 was first made available in 2011 but only in 2013 went into general availability. It supports full text indexes with innodb, which we've discussed before with ColdTrick.

I'm in favor of using utf8mb4 where available, but see no need to bump our requirements.

I'm running Elgg on MariaDB, so I would like to keep it as an option and not include features used exclusiely in MySQL.

FYI  MariaDB 10.0.5 has fulltext indexes on InnoDB

utf8mb4 works on my MariaDB 10.0.4, but not sure when it was introduced.

I think we'll need to move to innodb at some point as we still have issues with non-atomic db operations. We need transactions for things like metadata.

Also when we start requireing PHP 5.3, we'll be able to incorporate libraries like doctrine, so other databases may come into the view. We shouldn't force features that are not common among them.

Personally I'm very interested in switching out the DB layer to a 3rd party library like Doctrine. None of us are DBAs and Elgg can sometime generate hilariously ugly queries.

I agree with Brett.

e. g.:
https://en.wikipedia.org/wiki/Propel_%28PHP%29
https://en.wikipedia.org/wiki/Doctrine_%28PHP%29

https://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP

It makes also easier to switch to another DB backend.

@al note that we don't talk here about introducing orm library, but dbal (database abstraction layer). I didn't say it clearly, but i 'm interested in adapting dbal part of doctrine only. I'd like to make it switchable to custom implementations as well.

Speaking of ugly queries, i didn't see any dbal that would take care of optimizing query for the programmer. We'll have to run explain's on queries ourselves regardless of library used.

+1 for DBAL. The query builder will help a bit when queries have to be built dynamically. Otherwise hand-written wins for clarity.

As I understand right elgg should use PDO

http://at1.php.net/manual/en/book.pdo.php

right?

Not the bare PDO, we want some abstraction over it, but yes PDO is a most likely backend we'll be using under the hood.

Sorry but now I'm complete confused.

No ORM!

No plain PDO!

Write own dbal.

Why not use a ORM, and only the DBAL Part not the ORM part?

e. g. Data Retrieval And Manipulation

Search for Using Custom SQL