-
Notifications
You must be signed in to change notification settings - Fork 204
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
Model: add -m option to change model: granite, crecto or jennifer #54
Comments
Perhaps we should remain ORM/REPO agnostic and add generators for different libraries? |
At the moment, I think this is the best we can do until we discuss technical details. |
It's actually pretty interesting that there's no built in model. This doesn't have to be another MVC. Having it handle routes, controllers, views, middleware, etc.. is quite a bit already. Being able to just plug in your own way of handling models and other business logic type stuff would be nice. Maybe there could be a separate shard for a "amber" type way of handling this stuff, but by default not in the amber shard. |
That being said, seeing how the router is inspired from Phoenix, I though I'd find Crecto in there too. As long as it is easy to swap parts, I think that an "all-in-one" opinionated model makes sense (even if I had a different opinion on the ORM 😉). |
@oz We are considering to support Crecto for a Repo pattern type of models and Granite/Jennifer for Active Record Pattern with generators we still thinking about this one |
-m
to new
that allows you to choose granite
, crecto
or jennifer
-m
to new
that allows you to choose granite
, crecto
or jennifer
Here is the example app created by @fridgerator for using crecto with amber: |
* #54 support crecto * minor bug fixes * float64 * fix auth migration * bug fixes
I am going to close this since we support |
* amberframework#54 support crecto * minor bug fixes * float64 * fix auth migration * bug fixes
* #54 support crecto * minor bug fixes * float64 * fix auth migration * bug fixes
Implemented in a way that separates the behavior that we want to express (entities) from the persistence layer (repositories and database). This design helps keep the interface of our objects small and therefore keeps them fast and reusable.
The text was updated successfully, but these errors were encountered: