Skip to content
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

Entity Concerns #662

Closed
Iamscalla opened this issue Aug 7, 2017 · 4 comments
Closed

Entity Concerns #662

Iamscalla opened this issue Aug 7, 2017 · 4 comments

Comments

@Iamscalla
Copy link
Contributor

for the entity of each model to work, it's required that the properties of each value be defined. to me it's of a huge concern, cus if I have a database table with a large amount of columns, I have to define all. Also which I do a joining, I also have to define all in the entity. also the make's the entity a kind of tedious task.
there should be a lighter mode of calling all properties without having to define everything.

@lonnieezell
Copy link
Member

In order for the Entity to be saved back to the database properly, it has to know what fields are part of it. I was trying to think of a solution, and the model has $fillable, which I imagine you'll also have a problem with :) but it doesn't include all of the fields that might need to be saved so I'm not 100% sure that will work. Will need to look back through the code this evening.

However, the pragmatic solution is, instead of trying to change things to save 5 minutes of typing, you spend a couple of hours to automate it for the future. I've already started that process for anyone using CI4.

@Iamscalla
Copy link
Contributor Author

looking at Vulcan, it still does not solve it. especially when doing table joining (the basic extent have tried implementing to). like you said, a code review would be better to proffer a better work around.

@lonnieezell
Copy link
Member

I'm not able to come up with a good solution, and I don't believe there is one.

  • The model's $allowedFields variable is there to protect against mass assignment errors, so that won't be going anywhere, so you'll already be typing the fields out.
  • There has to be some way to save the entity back to the database, so it would have to know what fields to try and save. If we were to remove those fields, and rely on the $fillable array, we would potentially miss some data on the way back in.
  • While most of the time, we could rely on $allowedFields to get the fillable names, it is possible to turn off the check that removes fields not in the $allowedFields array, and if the Entity itself doesn't know about it there's no way to save that to the model.

The Entity class is an optional class on top of the database layer, anyway, so no one's forcing you to use it. You could always create your own base entity class if you wanted, tailored to your workflow.

I looked at how the largest database system that I know of that uses a similar pattern as this system does things (Doctrine) and the entity class has to define each field type as well.

@Iamscalla
Copy link
Contributor Author

Ok, @lonnieezell , i would not give up on it. would make some research on it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants