Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

please add some docs #5

Open
evnix opened this issue Sep 5, 2019 · 3 comments
Open

please add some docs #5

evnix opened this issue Sep 5, 2019 · 3 comments

Comments

@evnix
Copy link

evnix commented Sep 5, 2019

Apart from the title,

Thanks for this!! I was wondering why aren't more people making this happen, using PHP 7.4 typed properties is an absolutely fantastic idea!!

Would it be as easy as writing models like?

 class Person{
    integer $id;
    string $name;
    Country $country;
  }

it would be nice if all tables were autogenerated (like spring-boot and grails etc),

and the usage would be as easy as:

 $p = new Person("John", Country.findByName("Australia"));
 $p.save();  // or PersonRepo.save($p)
 PersonRepo.get(1)
 Person.get(1) //even better

other variations:

CountryRepo.findByIdAndName(3, "Australia");
CountryRepo.findByNameLike("Aus%");
CountryRepo.findAllByNameIn(["Korea", "Japan", "Australia"])

GORM(Hibernate based) is one of the best ORMs from the Java/Groovy world, would be nice if can copy those features:
http://gorm.grails.org/latest/hibernate/manual/index.html

Would be interesting to see how it integrates with laravel (I'd rather use PDO than use Eloquent )

@BenMorel
Copy link
Member

BenMorel commented Sep 5, 2019

Hi, thanks for your interest! I didn't expect any feedback so early, as I'm really just playing with some ideas right now.

Yes, the basic idea is to be able to use typed properties and have little to no configuration, as the ORM should be able to infer types for scalars and object relationships (at least *-to-one, I'm not working on *-to-many yet and they will require some sort of configuration due to not having generics in PHP—hopefully in PHP 8?).

It's not going to work as you're suggesting above though: what you're suggesting is active record, meaning that the objects have knowledge of the ORM and know how to persist themselves.

Instead, entities will be plain-old PHP objects, that will not need to extend a base class:

class Person { // no extends like active record ORMs
    public int $id;
    public string $name;
    public Country $country;
}

class Country {
    public string $code;
}

$person = new Person;
$person->name = 'John';
$person->country = new Country;
$person->country->code = 'GB';

$orm->save($person);

My current goal is to be able to handle low- and high-level use cases with a single ORM, and even be able to mix different approaches in a single application depending on the requirements of each component:

  • full-fledged ORM with identity map and change tracking (similar to Doctrine) when complex relationships / business rules are in use:
    $person = $orm->load(Person::class, 1);
    $person->updateSomething();
    $orm->flush();
  • basic data mapper to perform low-level DB operations when top performance is required but you don't want to give up your clean OO API:
    $person = new Person;
    $person->name = 'John';
    $mapper->insert($person);
    $person = $mapper->load(Person::class, 1);
    $person->name = 'Jack';
    $mapper->update($person);
  • and finally, the ability to hydrate complex (nested) data transfer objects / view models from raw SQL queries:
    $persons = $gateway->nativeQuery(Person::class, <<<SQL
        SELECT
            p.id,
            p.name,
            c.code AS country__code
            FROM Person p
            JOIN Country c ON ...
    SQL);

Anyway this is all very raw at the moment, and I'm not planning to add docs before I get something working and reasonably stable. My goal is to have something just in time for the PHP 7.4 official release, if I get enough time to work on it.

Stay tuned and ⭐ the project ;)

@evnix
Copy link
Author

evnix commented Sep 9, 2019

Thanks for the indepth explanation.

and finally, the ability to hydrate complex (nested) data transfer objects / view models from raw SQL queries

This would be a complete game changer!!

It's not going to work as you're suggesting above though: what you're suggesting is active record, meaning that the objects have knowledge of the ORM and know how to persist themselves.

You are right and makes sense.

I don't know if the following is even feasible,

I really like how Grails/Spring-JPA allows you to change the entity and the table structure changes in the next run.

Doctrine does this as well but is not nearly as automated as Grails/Spring-JPA. I think it allows you to generate migrations from your entities.

Redbean does this as well, https://redbeanphp.com/index.php

@BenMorel
Copy link
Member

BenMorel commented Sep 9, 2019

I really like how Grails/Spring-JPA allows you to change the entity and the table structure changes in the next run.

(...)

I'm not fond of using too much magic, I personally like to keep control over my database schema, so I would definitely not make the ORM update your schema automatically.

However, having used Doctrine Migrations, I do see the value of having a migration script auto-generated on demand, and I'm fine with this approach, as long as you have full control on it (I mean being able to review/modify it before committing it and running it), and definitely not upgrade the schema without your consent :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants