In your example in the REAME.md you show how pretty code can look when you can just do something like $gallery = new Gallery('Trip to India') and $photo = new Photo($file).

However, I notice in daily life with Laravel I rarely use that. I much more often use form-data to populate new entities and I really liked that with Eloquent I could mass-assign that like so: $user = new User($request->all()). And because I had set a $fillable property on User I knew that I wouldn't populate non-existing attributes or special attributes. And even all the right mutators would be called.

I think that use-case is much more likely in daily life. What do you think?

And I took it even one step further. I made my own base-eloquent-model in which I had my own constructor like so:

public function __construct(Request $request)
{
    parent::construct($request->input(class_basename($this)));
}

This way, in my controllers I could do something like:

public function store(CreateUserRequest $request, User $user, Person $person)
{
    $person->save();
    $user->associate($person);
    $user->save();
}

Because just by type-hinting all that stuff I knew that the data had been validated and correctly mass-assigned to the respective models. That is just so freaking convenient, can we please build something similar into Analogue?

In case you're wondering, this is basically what my form would look like:

<form>
    <input name="Person[name]" type="text">
    <input name="Person[infix]" type="text">
    <input name="Person[surname]" type="text">

    <input name="User[email]" type="email">
    <input name="User[password]" type="password">
    <input name="User[password_confirmation]" type="password">
</form>

I have error with cache if using VO for identity property (PK):

2) UserRepositoryCest: Save
 Test  tests\integration\Infrastructure\UserRepositoryCest.php:save

  [PHPUnit_Framework_Exception] array_key_exists(): The first argument should be either a string or an integer

Scenario Steps:

 1. $I->takeContainer() at tests\integration\Infrastructure\UserRepositoryCest.php:30

#1  Codeception\Subscriber\ErrorHandler->errorHandler
#2  \vendor\analogue\orm\src\System\EntityCache.php:95
#3  \vendor\analogue\orm\src\System\Aggregate.php:1010
#4  \vendor\analogue\orm\src\Commands\Store.php:39
#5  \vendor\analogue\orm\src\System\Mapper.php:171
#6  \vendor\analogue\orm\src\System\Mapper.php:132
#7  \Infrastructure\Repository\AnalogueUserRepository.php:164
#8  \tests\integration\Infrastructure\UserRepositoryCest.php:71
#9  Infrastructure\UserRepositoryCest->save

/**
     * Check if a record for this id exists.
     *
     * @param  string  $id
     * @return boolean
     */
    public function has($id)
    {
        return array_key_exists($id, $this->cache);
    }

As discussed in #171.

With a simple User and Group mapping, many-to-many relationships load an empty result set if either map has a modified $primaryKey.

That is:

$users = $userMap->with('groups')->get(); means no users will have groups, and vice versa.

In my case, the GroupMap has a $primaryKey of 'groupid'. If I rename the column in the database schema to id, and remove the custom $primaryKey from the map, everything works as expected.

I'm using a custom connection for this, but this happens with or without the custom connection; I've tested both. However, as a result I noticed that the ID was bound as null when the query is run, and digging a little deeper it looked like the proxy object that represented the parent of the relationship had no attributes.

The STI implementation that we worked on a couple of months ago is still unusable for me without this PR; I have it implemented on the 5.1.* branch of my fork (I use it for an app I've been building at work and this solution works nicely), but we're upgrading the app to Laravel 5.3 and I need to use the 5.3-dev branch branch and this never got merged into the original PR. We talked about this in the conversation for the previous PR: https://github.com/analogueorm/analogue/pull/131#issuecomment-245150719. Please consider merging this in, for the reason discussed in that comment thread. Also, if you want help writing tests for this feature (or anything else that I can help with) just let me know. I'm in Laravel slack as tabennett. Thank you for your time and work you put into this project.

I've taken a stab at implementing #101. This is probably going to need some cleanup, but I've tried to following the concepts that you laid out (namely, using higher level ResultBuilder that builds out an array of entities by calling each the appropriate ResultBuilder for each record). To implement table inheritance, all you have to do is define some meta values on the base mapper class. As example, we could define the following configuration on a base Vehicle mapper:

/**
     * @var string
     */
    protected $inheritanceType = "single_table";

    /**
     * @var string
     */
    protected $discriminatorColumn = "type";

    /**
     * @var array
     */
    protected $discriminatorColumnMap = [
        "vehicle" => "App\Entities\Vehicle",
        "car"     => "App\Entities\Car",
        "truck"   => "App\Entities\Truck"
    ];

This follows the same inheritance mapping configuration as used by Doctrine. I did this for the following reasons:

1. People that have used Doctrine before and are familiar with this configuration will be able to get up and running quicker.
2. This opens the door for us to implement class table inheritance later on (which would be very nice to have but is beyond the scope of this PR).

The only major issue I have with this is that I wasn't able to figure out how to get an instance of the Manager class without using Laravel's IOC container (which might not be the most ideal way to do that and feels a bit weird to be doing). Please let me know what you think.

@devsi and I have started using this library and it's truly fantastic.

However, we've encountered an issue with the BelongsToMany relation when it's eagerly loaded as a nested relation. I imagine this might be an issue with the version of Eloquent you forked, after some investigation, but I can't be certain.

It would be nice to know whether this is actually a bug, or whether we're doing something wrong.

Here are the relations in our system:

• Quizzes many to many Questions
• Questions one to many Options

We have one Quiz, with three Questions, each having a number of Options.

If we eagerly load Options with their parent Questions, as well as the Quizzes of those Questions like so:

$options = $optionMapper->with('question.quizzes')->get();

It ends up that only the last pivot for Quizzes is actually taken into account, seemingly because all of these will be the same Quiz (ID 1).

Here's the result set with eager loading:

https://pastebin.com/0FC1Vb88

Here, only the last loaded Quiz pivot is included.

Here's the correct result set with lazy loading, or if we only eager load questions (with('question')):

https://pastebin.com/sGBM01qY

Here, all the pivots are loaded properly without eager loading.

If need be, I can make these result sets much simpler and even provide the queries run, but I thought I'd just outline it for time being to see if you knew about this.

I traced to the BelongsToMany::match() method having a dictionary with a single item, instead of three.

When System\Query::loadRelation() is run for this relationship, the $results collection indeed only contains the last pivot, but if I run the corresponding SQL result manually on my database, the results include all three.

Cheers!

Hey, I was wondering if there is (currently) a way to implement table inheritance (single, join, etc) with Analogue, and if not, maybe we could hash out some ideas here. From looking at some of the underlying system classes, I would assume that this is not going to be trivial to implement. If there's anything I can do to help, please let me know. I think having a nice and clean way to do STI with Analogue would help a lot of people or are transitioning from AR to DM in their Laravel based apps and could really strengthen support for this project.

Is it possible to use Laravel/Lumen 5.1 LTS i.e. the Illuminate 5.1 packages? For now 5.0.* is defined as the only compatible version in composer.json.

I've created a Presenter class (ala Jeffrey Way's Presenter class): https://github.com/smallhadroncollider/analogue-presenter

If you would like to, I'd be happy for it to be added to the Analogue GitHub organisation, then it can use the Analogue namespace. Let me know if you'd be happy to do that and I'll setup a transfer request. If not I'll just do it under my own namespace instead.

Okay, let me explain why is this really MUST be implemented.

As you may know Postgres uses sequences to generate auto-incremented id's, that's more reliable method to implement auto-increments than MySQL's one. This gives us more control over lastInsertedId command.

Why you really need to implement this feature? Because of the way how Postgres executes commands, sometimes there is something else saving in paraller of other row and that gives a collision (from our perspective), more known as race condition, in that situation when we call lastInsertedId w/o defining from which sequence we want it we will get id of a wrong row in wrong table or get just NULL because row saved in parallel has no primary key.

So in conclusion: sequence feature will eliminate race conditions.

Here is a quote from a php's manual for PDO::lastInsertId:

Returns the ID of the last inserted row, or the last value from a sequence object, depending on the underlying driver. For example, PDO_PGSQL requires you to specify the name of a sequence object for the name parameter.

Laravel already supports it

to illustrate the problem i have two tests...

     /**
     * @test
     */
    public function it_creates_a_user()
    {
        $userMapper = \Analogue::mapper(User::class);
        $user = new User(new Identity('first name', 'last name'));
        $userMapper->store($user);
        $user = $userMapper->find(1);
        $userMapper->store($user);
    }

    /**
     * @test
     */
    public function it_updates_a_user()
    {
        $userMapper = \Analogue::mapper(User::class);
        $user = $userMapper->find(1);
        $userMapper->store($user);
    }

first one is ok, second one (record with id 1 exists in database ) fails with the message:

Illuminate\Database\QueryException: SQLSTATE[HY000]: General error: 1 no such column: first_name (SQL: update "users" set "first_name" = first name, "last_name" = last name where "id" = 1)

I can't install Analogue on fresh installation of Laravel 6 This is my composer.json

 "require": {
        "php": "^7.2",
        "fideloper/proxy": "^4.0",
        "laravel/framework": "^6.0",
        "laravel/tinker": "^1.0"
    }, 

and this is the error produced when trying composer require analogue/orm:6.*

./composer.json has been updated

Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Conclusion: don't install analogue/orm v6.0.1
    - Conclusion: don't install analogue/orm v6.0.0
    - Conclusion: remove laravel/framework v6.18.6
    - Installation request for analogue/orm 6.* -> satisfiable by analogue/orm[6.0.x-dev, v6.0.0, v6.0.1].
    - Conclusion: don't install laravel/framework v6.18.6
    - analogue/orm 6.0.x-dev requires illuminate/database 6.0.* -> satisfiable by laravel/framework[v6.0.0, v6.0.1, v6.0.2, v6.0.3, v6.0.4], illuminate/database[v6.0.0, v6.0.1, v6.0.2, v6.0.3, v6.0.4].
    - Can only install one of: laravel/framework[v6.0.0, v6.18.6].
    - Can only install one of: laravel/framework[v6.0.1, v6.18.6].
    - Can only install one of: laravel/framework[v6.0.2, v6.18.6].
    - Can only install one of: laravel/framework[v6.0.3, v6.18.6].
    - Can only install one of: laravel/framework[v6.0.4, v6.18.6].
    - don't install illuminate/database v6.0.0|don't install laravel/framework v6.18.6
    - don't install illuminate/database v6.0.1|don't install laravel/framework v6.18.6
    - don't install illuminate/database v6.0.2|don't install laravel/framework v6.18.6
    - don't install illuminate/database v6.0.3|don't install laravel/framework v6.18.6
    - don't install illuminate/database v6.0.4|don't install laravel/framework v6.18.6
    - Installation request for laravel/framework (locked at v6.18.6, required as ^6.0) -> satisfiable by laravel/framework[v6.18.6].


Installation failed, reverting ./composer.json to its original content. 

Hello, just trying to use eager load: Mapper:

class RoleMap extends EntityMap
{
    public $timestamps = true;
    protected $with = ['roleStrings'];

    public function roleStrings(Role $role)
    {
        return $this->hasMany($role, RoleString::class);
    }
} 

If I trying this:

return mapper(Role::class)->find($id);

Relations not loading automatically.

But if I trying this:

return mapper(Role::class)->with(['roleStrings'])->find($id);

OR

return mapper(Role::class, RoleMap::class)->find($id);

All relations was loaded well.

So I'm just want to know there a bug or I doing something wrong?

I was working on upgrading to 5.5 and ran into some issues with the serialization. To be exact I upgraded analogue/orm from 5.4.0 to 5.5.18.

Basically in 5.5 the EntityProxy was replaced with a new ProxyFactory and when creating the generated class there is a closure inside. PHP is unable to serialize closures and fails with an exception:

Serialization of 'Closure' is not allowed

I ran into this when passing in my User entity to Notification::send(...) or when calling $user->notify(...). My User entity is still using the 5.4 base class and implements Notifiable. The serialization issue happened when the Queue tried to serialize the job (which contains the notifiable user).

I tried to work around this by implementing the Serializable interface and calling $this->toArray() and such but was not able to cover all the cases. Also upon a fresh boot Analogue ORM would throw an exception due to not being able to serialize() the dummy entity. Removing my overrides restored the original behavior.

I hacked a workaround by manually unsetting any proxied entites or collections but this isn't maintainable. I can probably separate User from Notifiable and create another class to deal with this but it all worked in 5.4 without issue.

My questions are:

• Is it intended for the new proxy behavior to not serialize?
• Any workarounds or fixes possible here?
• If no workarounds or fixes: do you know what is the correct way to deal with serialization issues like this?

I would greatly appreciate any insight into this problem. Maybe I'm just doing something wrong but since this all worked in 5.4 it feels like a regression.

I'll just describe here the most obscure points

• Since 5.5 Repository was marked as deprecated, what is alternative - full custom realizations with mapper injection, or something else?
• Accordingly https://github.com/analogueorm/analogue/issues/142 there is ability to map entity attributes to column names - what about similar behavior for properties?
• Example for transactions
• Example for incremental/decremental operations ( with queries like UPDATE table SET "foo"="foo"+1)
• Pros and cons for embedded objects instead of classic valueObjects via getters and setters

  // ...
  public function setStatus(StatusObject $status){
       $this->status = $status->getValue();
       $this->code = $status->getCode();
  }
  public function getStatus():StatusObject{
       return new StatusObject($this->status, $this->code);
  }

Of course, embedded objects are resolved automatically, but in some cases they can bring overhead?

Hello, Great job with this package. It works great with my projects. Is there a package that makes translations of models? I need somethig like dimsav/laravel-translatable.