Timeline for How are globals any different from a database?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 2 at 18:52 | comment | added | Basilevs | The correct answer is rated fourth, ridiculous. | |
| Feb 23, 2017 at 2:04 | comment | added | Lie Ryan | @jpmc26: DI is difficult to demonstrate in one liner, and I don't have space for lengthy comments here. But DI or no DI in the sample code makes no difference, since the code in modify_data never calls commit/rollback/savepoint itself, DI and transaction becomes orthogonal issue. With DI, you can even switch the objects you pass around with a mocked or an in memory objects, and your data modifying code need not be aware/care whether or not it's talking to a database. | |
| Feb 22, 2017 at 16:52 | comment | added | jpmc26 | @LieRyan ? Your example doesn't have any DI. | |
| Feb 22, 2017 at 12:59 | comment | added | Lie Ryan | @jpmc26: with db.begin() as session: modify_data(session), rollback happens by raising exception, commit happens by returning from modify_data(), savepoints happens by making subtransaction contexts. This is one example of well-structured transaction handling: start transaction, commit, and rollbacks all happen in the same function. What operations happens as a group is trivially answered by simply stepping through modify_data(). Refer to sqlalchemy for an example database library that makes this kind of structured transaction handling straightforward. | |
| Feb 22, 2017 at 2:07 | comment | added | jpmc26 | @LieRyan "Never" is a strong word. That said, yes, commits should done at the highest appropriate scope possible, although that isn't always a single point in a sequence. Also consider it the other way around: how do I know what database operations are done as a group on a single transaction? The problem is that the structure of the code no longer tells me about the relationships between the different scopes; I can't follow the code and easily tell which things use the same transaction. DI takes this kind of scope control out of your hands, breaking it up into tiny disconnected pieces. | |
| Feb 22, 2017 at 1:59 | comment | added | Lie Ryan | @jpmc26 I don't think that's the fault of DI. Code that modifies the data in database should never call commit itself. Transaction management should always be structured such that commit is called in the same function/scope as the transaction start. If you have commits sprawling all over the code, that's like the same evil as unstructured programming. | |
| May 31, 2016 at 9:46 | comment | added | jpmc26 | @EmilLundberg No, the problem is when you have a hierarchy. Dependency injection hides the dependencies of lower tiers from the code in the higher tiers, making it difficult to keep track of which things interact. For example, if MakeNewThing depends on MakeNewThingInDb and my controller class uses MakeNewThing, then it's not clear from the code in my controller that I'm modifying the database. So then what if I use another class that actually commits my current transaction to the DB? DI makes it very difficult to control the scope of an object. | |
| May 31, 2016 at 9:39 | comment | added | Emil Lundberg | @jpmc26 I might be marking words, but isn't the above a good example of how dependency injection (as opposed to global lookup) helps make dependencies explicit? It seems to me like you rather take issue with certain APIs, like perhaps the annotation magic used by JAX-RS and Spring. | |
| May 28, 2016 at 1:04 | comment | added | jpmc26 | +1 On a side note, this answer pretty much explains what I hate most about dependency injection. It hides these kinds of dependencies. | |
| May 27, 2016 at 17:39 | comment | added | Andres F. | +1 Different threads or apps writing and reading from the same database is a potential source of a large number of well-known problems, which is why there should always be a strategy for dealing with this, either at the database or app level, or both. So it's definitely NOT true that you (the app developer) don't care about who else is reading or writing from the database. | |
| May 26, 2016 at 0:56 | comment | added | user186205 | Yeah, I thought it was interesting when the OP said: "You don't care what the data is; that's the entire point" - if we don't care, then why store it? Here is a thought: let's just stop using variables and data at all. That should make things much simpler. "Stop the world, I want to get off!" | |
| May 25, 2016 at 1:10 | history | answered | Michael Anderson | CC BY-SA 3.0 |