Lithium101 is an unofficial community resource for the Lithium PHP framework indexing articles, tutorials, code snippets and libraries.
Tracking 261 plugins, categorised and sorted. If you are the plugin owner you can edit the status and category.
So far there are 54 Lithium related snippets. It's super easy to add your gists as snippets on the site, if there is anything you think might be interesting or helpful take a minute to share it.
I agree on @koushki for two reasons: 1. As a developer i expect that to happen 2. As a bad developer, i do not care and might blame the framework for that As an addition, as soon, as i notice that _updated_ fields are going to be tracked inside entity, it seems obvious that a save only updates changed fields. If that is not the case, it should be clearly stated, somewhere. Before i state something like that somewhere, i would change the default behavior to something, that does not need an explanation. d1rk
No, i think both of them are related . if we fix issue #1121 we don't need to above changes. We can validate only fields that has changed if only we save them. In this solution if developer set `'required' => true` we validate this field even it didn't change. Also in this way we don't need to change document and it's clear. What's your opinion? koushki
I believe framework should be trusty for enterprise projects. I think solving of this problem is important for version one. Maybe this happen in special cases, but if happened, it can be problematic because it make a logic error in project and it change data without ability of reversible. it's clear that is very hard to find source of this problem. koushki
@koushki I don't think #1121 has to block this issue. Those issues are independent from each other. davidpersson
The current default behavior for SQL databases is to do a full replace instead of an incremental update when saving an existing entity having all fields. I agree that this is something which can/should be optimized. I don't agree about the severity of this missing feature. It becomes only a problem if you rely on the atomicity of updates _and_ have a high amount of concurrency _and_ retrieved all fields. This feature could be implemented in the `Database::update()` and `Database::create()` methods similar to how its done with `MongDb` using its own Exporter class. For this case we may not even need a dedicated exporter class unless there's more code involved. davidpersson
@davidpersson ,@netable please don't merge this commit. I found a bigger bug in `Entity` and i reported in #1121 issue. after fixing #1121 issue, we can use better way for this case. koushki
Please commit as you see fit directly once you have write access. davidpersson
@koushki Model::validates() would be the best place. davidpersson
thanks everybody for your opinions, I changed previous way to confirmed way. @jails please check and give me your opinion. @davidpersson I wanted to change documents but i don't know where is better, I confused among: + `validates` property in `Model` + `validates` method in `Model` + `check` method in `Validator` koushki
Yup, I should be able to provide something the new W.E. ! jails
Alright, @jails would you like to lead the implementation and work on it together @koushki? Granted you both would like to and have time. davidpersson
@davidpersson Yeah I'm pretty much in agreement with @jails. nateabele