brick / orm

Object-relational mapper for PHP 8 - Currently in development 🚧
10 stars 1 forks source link

please add some docs #5

Open evnix opened 4 years ago

evnix commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

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 :)