5 ms·
I can see that working if each of the 7 tables was their own individual entity, but I am talking about a composite object here. Normalized data. How do you man
by angrycoder 16y ago
I can see that working if each of the 7 tables was their own individual entity, but I am talking about a composite object here. Normalized data.
How do you manage a transaction across 7 different controller methods?
I am not saying their isn't a nice way to do this, merely using this as an example of why people may not like Rails. It forces you to figure out the Rails way of doing things. And that may not always be the best way for you, especially if you are an experienced developer.
- johnbender 16y agoYou're describing a problem that arises as a consequence of using an ORM, any ORM, which is not at all Rails specific.
- angrycoder 16y agowhen you have to spread your updates across 7 different controller actions (methods) to make it work the Rails way, it most certainly is a rails problem.
- vowelboy 16y agoYou're assuming that there is a hard coupling between Controllers and Models. There isn't. Rails suggests a CRUD pattern, but doesn't enforce it. You can quite easily (and elegantly) update 14 different tables from one form, using one request and one controller method.
- generalk 16y agoYou can quite easily (and elegantly) update 14 different tables from one form, using one request and one controller method. You can very transparently do it with ActiveRecord associations, so that you're operating on only one instance of a model, or you can do it very opaquely, where you instantiate and update several models. Or you can just run an UPDATE statement; those haven't gone away.