-
Notifications
You must be signed in to change notification settings - Fork 88
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
Modulize Granite::ORM #49
Comments
@c910335 yes, I agree long overdue. I like your proposal. We are also looking to move Kemalyst::Validators into Granite::ORM so this modularization would be a welcome change. Is this something you will be working on? |
If there is no progress by now, I am going to deal with this. |
I"m not aware of anyone working on this. thanks @c910335 |
Why are there so many class methods defined in the macro |
This is remnants from before having the ability to do a I believe they used to have macro variables. If we can remove them from the macro now, we should. |
Forgot associations.cr |
I think it is time to modulize Granite::ORM because
src/granite_orm.cr
is too complicated to add new features.The following are my suggestions.
Renaming
Granite::ORM
toGranite::ORM::Base
If we want to split
Granite::ORM
into modules, those modules should be inside a module which is very likely to be named asGranite::ORM
. Thus, renaming the original classGranite::ORM
toGranite::ORM::Base
is necessary although it is a breaking change.The Plan for Modulizing
src/granite_orm
, declare classGranite::ORM::Base
, include(extend) the modules and constructorsfield
,timestamps
,process_fields
(but this is still too large and need partitioning), and methodset_attributes
adapter
,table_name
,primary
save
,destroy
require "./granite_orm/base"
There may be some difficulties and this plan still needs improvements, so let's start discussing.
The text was updated successfully, but these errors were encountered: