Currently, the encrypter class lets you select broken ciphers. I propose restricting the ciphers you're allowed to select. If a broken cipher is selected, an \InvalidArgumentException should be thrown.

Hi, great project.

Your code is very consistent but doesn't always match Symfony / PSR style. For example: Use of double quotes instead of single quotes even though there is no "$var" inside the string, single line PHPDoc comments for class properties, ...

It would be nice if you could publish a document explaining what style you expect contributors to adhere to.

Bonus points if I could import it into PHPStorm.

Thanks.

It would be nice if the query builder supported a whereIn function, along with orWhereIn. This is something I miss quite often also in other frameworks.

Example usage:

use Opulence\QueryBuilders\PostgreSql\QueryBuilder;

$query = (new QueryBuilder)->select("id", "name", "email")
    ->from("users")
    ->whereIn("id", [1, 2, 3])
    ->orWhereIn("email", ["[email protected]", "[email protected]"]);
echo $query->getSql();

This would output:

SELECT id, name, email FROM users WHERE id IN (?, ?, ?) OR email IN (?, ?)

I wouldn't mind giving implementing this a shot, the only question is whether this should default to using named or unnamed parameters. Perhaps it could default to unnamed, with an optional parameter to use named parameters? I'd like to hear what you think.

Nice framework but unfortunately phpDocumentor does not read the IO\Stream folder probably because Opulence uses reserved names or because it does not support: void as return value.

Unfortunately I do not know the reason.

Could you resolve please?

Thank you

While developing AbterPHP, I ran the migrations hundreds of times and it kept bugging me to debug query errors, because currently the migration commands wouldn't even tell me that there was an error. With these changes I would be able to create a migration class like this:

<?php

declare(strict_types=1);

namespace AbterPhp\Framework\Databases\Migrations;

use Opulence\Databases\Migrations\Migration;

class BaseMigration extends Migration
{
    // ...

    /**
     * @inheritdoc
     */
    public function down(): bool
    {
        $sql       = 'SELECT 1';
        $statement = $this->connection->prepare($sql);
        if (!$statement->execute()) {
            $this->errors = $statement->errorInfo();

            return false;
        }

        return true;
    }

    /**
     * @inheritdoc
     */
    public function up(): bool
    {
        $sql       = 'SELECT 1';
        $statement = $this->connection->prepare($sql);
        if (!$statement->execute()) {
            $this->errors = $statement->errorInfo();

            return false;
        }

        return true;
    }
}

Obviously this change would warrant at least a minor version bump, if not a major one.

The entire environment setup is quite confusing to use. While it is possible to integrate it with other tools such as phinx, it isn't easy nor convenient.

Dotenv is a fantastic package maintained by Vance that provides a seamless environment configuration experience. Simple to use and share between tooling.

Could a move to using Dotenv be considered? Taking advantage of it will provide the best experience to developers.

There are two main topics to be solved:

1. Some PDO adapters are not compatible with \PDO classes they extend (Connection, Statement)
2. Reflection usage. Especially relying on the now deprecated ReflectionParameter::getClass. Additionally it seems like something has changed in regards to tokenization / autoloader, because the ReflectionClass constructor fails for the parsed migrations in FileMigrationFinder

Issue description

The executedmigrations table will contain the datetime of the execution in the daterun column and this would be then used for finding the latest executed migration if you ran ./apex migrations:down. The problem is, if you ran previous migrations at once before, this will not provide a sufficient way to select the latest migration run. Instead it will pick a random one executed in the exact second of the truly last executed one.

Example

Code

namespace AbterPhp\Users\Databases\Migrations;
// ...
class Init extends Migration
{
    // ...
    public static function getCreationDate(): DateTime
    {
        return DateTime::createFromFormat(DateTime::ATOM, '2019-02-28T21:00:00+00:00');
    }
    // ...
}

namespace AbterPhp\Pages\Databases\Migrations;
// ...
class Init extends Migration
{
    // ...
    public static function getCreationDate(): DateTime
    {
        return DateTime::createFromFormat(DateTime::ATOM, '2019-02-28T21:01:00+00:00');
    }
    // ...
}

namespace AbterPhp\Files\Databases\Migrations;
// ...
class Init extends Migration
{
    // ...
    public static function getCreationDate(): DateTime
    {
        return DateTime::createFromFormat(DateTime::ATOM, '2019-02-28T22:00:00+00:00');
    }
    // ...
}

namespace AbterPhp\Contact\Databases\Migrations;
// ...
class Init extends Migration
{
    // ...
    public static function getCreationDate(): DateTime
    {
        return DateTime::createFromFormat(DateTime::ATOM, '2019-02-28T23:00:00+00:00');
    }
    // ...
}

Database

| migration | daterun | --------------| -----------| AbterPhp\Users\Databases\Migrations\Init | 2019-03-04 12:03:43 | AbterPhp\Contact\Databases\Migrations\Init | 2019-03-04 12:03:44 | AbterPhp\Files\Databases\Migrations\Init | 2019-03-04 12:03:44 | AbterPhp\Pages\Databases\Migrations\Init | 2019-03-04 12:03:44 |

It may any of the last 3 for migrate:down.

Incomplete list of potential fixes

1. Replace daterun column with a time format which will contain some high resolution time. (Backwards compatible, but requires a schema upgrade)
2. Store the getCreationDate in a column and use that as a second sorting parameter when selecting the "last run" migration.
3. Retrieve all migrations run at the same time as the "last" one and select the migration with the latest getCreationDate returned. (Backwards compatible and no schema upgrade necessary, but he query will be somewhat harder to understand, and could lead to problems if someone changes the getCreatedAt value of a migration.)
4. ~~Sleep 1 second before executing consecutive schema upgrades.~~ :smile:

Note: Using microseconds as high resolution time is probably enough in most cases although it might just make it harder to reproduce the issue. Giving an option to use hrtime instead could have benefits, but only doable in PHP at the moment afaik. (https://pecl.php.net/package/hrtime, http://php.net/manual/en/function.hrtime.php) Without hrtime precision it might make sense to combine more solutions too.

I just installed the skeleton, but was receiving this error:

/project$ php apex app:runlocally
Running at http://localhost:80
[Fri Dec 22 11:05:39 2017] PHP Warning:  Unknown: failed to open stream: No such file or directory in Unknown on line 0
[Fri Dec 22 11:05:39 2017] PHP Fatal error:  Unknown: Failed opening required '/project/public/localhost_router.php' (include_path='.:/usr/share/php') in Unknown on line 0

This patch I am submitting fixed the issue for me.

The Opulence starter project sets ENV_NAME as an environment variable, and that environment variable is then used to set the Environmnet::name. If the ENV_NAME variable is changed, or the Environment::name member is changed, the two values would no longer have been equal.

One thing I learned is that there's a cache file for console that almost instantly gets cached in tmp/framework/console called cachedBootstrapperRegistry.json and say if you remove a bootstrap class it'll throw a fatal error making apex compeltely unusable because it's looking for a class that doesn't exist anymore.

My suggestion is to be able to call: php apex --hard-cache-clear which does one thing and that's to clear the cache directly and nothing else that way you won't have to manually do it to get apex working again.

I'm still learning Opulence, so maybe I'll try creating a PR if I figure it out tonight.