-
-
Notifications
You must be signed in to change notification settings - Fork 844
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
[Eloquent] Add basic data provider / persister #4197
base: main
Are you sure you want to change the base?
[Eloquent] Add basic data provider / persister #4197
Conversation
0c8835a
to
a7ac21e
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
df6515b
to
c43187e
Compare
Just my 2 cents: Back in 5.x days of Laravel, supporting Eloquent outside the Laravel framework was indeed very difficult and required quite a lot of hacking. Since the introduction of semver in Laravel 6.0, I've found adding support for newer versions to be much much easier. I even changed the version constraints from a specific minor to a specific major in my bundle. Upgrading from major to major has been smooth sailing as well:
In other words: I'm quite positive about maintaining support for the newer Eloquent versions once the implementation is build (and respect to @alanpoulain for going through the initial work on that!). |
Hello @wouterj. Thanks for your input. It's great to know that the Laravel ecosystem is becoming more professional since the introduction of semver and that the bundle will follow the future Eloquent versions as well! |
458973a
to
e305079
Compare
e305079
to
364cce5
Compare
54f0574
to
61f295c
Compare
61f295c
to
3f28328
Compare
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
First step of having an Eloquent support in API Platform. No filter and extension (no pagination) for now.
Eloquent support is based on the great WouterJEloquentBundle.
Some inspiration has been taken from EloquentSerializer.
In order to list the properties of the resource (since Eloquent models don't have this information), this PR brings two possibilities:
$apiProperties
class property,Being "magic" by retrieving the properties in the table, like it's done for instance in larastan, could be done afterwards (but there are some issues, for instance the migrations need to have been executed beforehand).
Related library: https://github.com/spatie/laravel-model-info
Only
crud.feature
andrelation.feature
are tested for now, the aim is to cover all the Behat tests in the end.Using Eloquent models as resources with
$apiProperties
class propertyExample:
Using Eloquent models as "data models" and link them to classical resources
The Eloquent data model should look like this:
Notice the usage of
snakeAttributes
in order to avoid issue when normalizing / denormalizing the Eloquent model.The resource should look like this:
This data model mapping has been thought to be compatible with all the providers. It should be compatible with Doctrine too (not tested yet).