Repository Structure
Introduction#
In this section, we'll discover the structure of a generated repository file.
Note
This structure is a bias one regardless the database engine used in the project.
A typical repository file structure#
The following example illustraes the repository structure regardless the database engine type.
Please note that this structure is used as an easier alternative for create update list methods.
Let's go in depth with the repository file
Repository name#
Here we defined the repository alias name that is used in the config/mongez.php file in repositories section.
Repository Main Model#
As a repository, it handles only one model for data insertion/update/delete or fetching, you can however work with more models in the declared methods.
In our example, it will be App\Modules\Users\Models\User model will be used here.
tip
The repository generator makes a class alias to model, filter or resource class at the class namespace declaration block for better usage.
Repository Main Resource#
Declares the main resource class that will be used in the Wrapping Methods in data fetching.
Storing/Updating Generic data#
Starting from this section, we'll start distributing our data in constants for more convenient way of data insertion/update.
This DATA constant accepts any type of data that can be stored directly without any manipulation or handling.
Not recommended
This constant is not recommended to be used unless there are some generic data that has no certain type.
Auto password encryption
If the constant array contains password column, it will be auto encrypted using the bcrypt function.
Storing/Updating String data#
Cast name, email, password inputs as string value in the create/update methods.
Auto password encryption
If the constant array contains password column, it will be auto encrypted using the bcrypt function.
Storing/Updating integer data#
Cast mobile_number input as interger value in the create/update methods.
Storing/Updating float Data#
Cast salary input as float value in the create/update methods.
Storing/Updating boolean data#
Cast newsletter_subscribed input as boolean value in the create/update methods.
info
If the boolean input is sent in he request as false in string it will be auto casted into false as boolean value.
Storing/Updating Localized Data#
This part of data is handled differently in each database engine, please refer to it in MYSQL Repository and MongoDB Repository
Storing/Updating Uploads#
This constant handles data uploading and storing in database.
Uploading files system has simple to advanced features, let's see it step by step.
Uploading single/multiple files#
UPLOADS constant accepts single file upload and multiple files upload, simply put the file column name and the managers will handle the two cases accordingly
Storing multiple files
Based on your database engine the multiple uploads database storage is handled differently, in MongoDB the uploads are stored as an array, while MYSQL stored data as json.
tip
This can be overriden by defining SERIALIZE_MULTIPLE_UPLOADS constant with a boolean value in your desired repositorty.
In MYSQL, the default value is true, while in MongoDB, the default value is false.
Ignoreable by default#
Any uploaded column is Ignoreable if there is no files uploaded in the update request.
If the model is being updated and there was a file uploaded in the creating step, for example user's avatar image is uploaded when user has created his/her accoumt, if user wants to update his/her profile and there is no avatar image is passed to the server, the avatar image will be remained the same old one.
Configurable options for each single column#
If you want to override default behavior for the previous options, you can override it by passing an array of options instead of the column name as follows:
Storing/Updating geo location data#
Store the location inputs as geo location data in the database.
This is handled differently in
MYSQLandMongoDBDatabases.
Storing/Updating date data#
Store birth_date in database as date, can be used for filtration using Carbon.
Declaring $dates property in the model
Any column defined in DATE_DATA constant must be defined in the $dates property in its corresponding model, otherwise searching by date won't work properly.
Storing/Updating arrayable data#
This array stores the data as json in database, can be usful for bulk data such as permissions list.
info
For MYSQL database, the data is stored as json, in MongoDB it is stored as sent, array or object.
When available data and ignoring values#
In all previous storage constants, if the column's value is not sent in the create or update method, the value will be cleared, unless the column is declared in the WHEN_AVAILABLE_DATA.
the
UPLOADSconstant is the only constant ignoring empty values and does not clear the value.
Let's see an example for its usage:
The user data will be name as Hasan and email as hassanzohdy@gmail.com.
Now let's update the user info
Now the user data will be name as Hasan and email as john@smith.com.
But what the email is not sent in the update process?
As the email is not ignorabe, it's value will be cleared, so the user data now will be name as Ali and email as empty string.
But if no data is sent at all?
The same applies, All columns will be checked if it is in the WHEN_AVAILABLE_DATA constant, in our example only the name is listed there.
So the user's data will be as follows:
Setting WHEN_AVAILABLE_DATA to true#
If the WHEN_AVAILABLE_DATA is set to true, any column that has no value will be kept with its current value.
User data will be:
User data will remain the same as no values are passed to any column.