harp-orm / harp Goto Github PK

I've decided to go with a Session "object" instead of numerous "Repo" objects.
Some thoughts about this:

• Moves us away from static classes and more into the realm of objects - greater testability, and more decoupled objects.
• Would be very nice for the pimple or other dependancy container.
• Follows more closely SQLAlchemy (Which I consider the state-of-the-art in ORM tech)

Things not to forget.

• Implement transactions on commit
• Expire identity map across transaction boundaries.

After looking into SQLAlchemy's source code, I've had some revelations:

• it uses a significant amount of magic and late binding, so if executed right, our thing can be quite a lot faster.
• each model has a reference to the session, but to avaid the var-dump problem (as well as probably general memory consumption) they use "session id" instead of a direct reference to the session in the model object. This is an approach I think we should also adopt.

Here is an example from the readme:

$user = Repo\User::get()->find(1);

How about something like:

$user = Model\User::find(8);

It would be just an alias to getRepo()->find(1).

Example implementation:

<?php

trait FindShortcuts {

    public static function find($id)
    {
        // static interface to `getRepo()` is to be implemented
        return static::getRepo()->find($id);
    }
}

This could make the interface very much like the Laravel's Eloquent ORM: http://laravel.com/docs/eloquent

Another change is the repo is more hidden from the end user for common operations.

I think it's good to expose the repo and make the interface explicit for persisting and operating on multiple records. But getting an instance of a single model could be so much easier.

What do you think?

External Graphs

I think the code should be much more understandable if all relationships are represented as links external to the model itself.

Reasons:

• Separate code for "links" outside of model, making the Model Class more decoupled
• More efficient aggregation - if it is a proper graph, then we can try to use known mathematical algos to solve problems
• "var_dump" will be far safer operation
• experiment with new concept

Requirements:

• get all affected once a model is loaded, all other models, loaded as relations to this model should be recorded as such and you should be able to easily get all "affected" models
• load related models on a single association - this for use of the default functionality of loading related models
• eager loading - load all models related to other given models, based on schema rel.
• eager loading - assign edges to the graph based on the loaded related models so that each model has its rels pre-loaded