9
votes
Fortnightly Programming Q&A Thread
General Programming Q&A thread! Ask any questions about programming, answer the questions of other users, or post suggestions for future threads.
Don't forget to format your code using the triple backticks or tildes:
Here is my schema:
```sql
CREATE TABLE article_to_warehouse (
article_id INTEGER
, warehouse_id INTEGER
)
;
```
How do I add a `UNIQUE` constraint?
I don't know about Rails but I can give some context.
MVC isn't a well-defined pattern. Models and views are often useful and coherent concepts, but nobody agrees what a controller is. Each framework just comes up with something that makes sense in that context and sometimes it gets called a controller, I guess out of tradition.
Models might seem more straightforward but they are less so in context. In an object-oriented, database-backed web app, the object "model" is often really more of a cached database entry; the system of record is the database.
And even database fields can sometimes be considered a cache of real world observations. There may be a Person record in the database but the actual person is out there walking around in the real world and their database entry may be inaccurate or out of date, depending on how often they update it and whether they tell the truth. Also, maybe the person doesn't really exist (a sock puppet), or there were two separate entities in the database for the same person. You might compare a database to a bucket of pebbles.
As for views, they really live in the browser, but there are often server-side representations of how they should be rendered.
I probably just muddied the waters further. I think you're better off learning how Rails does it and then deciding whether it makes sense in its own terms.
One of my favourite examples is Django where it could be argued that the model is fairly well defined (mostly a code representation of the database, potentially with some methods cooked into it), the controller is fairly well defined (it's the code that you put in
views.py) and the view is fairly well defined (it's what you put in your template files).Apparently they don't call themselves MVC either. It's Model-View-Template.
In Go, you just have HTTP handlers, whatever structs you define to hold SQL query results, and HTML templates. There is no pretending that it's MVC at all.
I'm aware they call themselves that, but it is, in my opinion, kind of a silly distinction.
Is there something specific to Ruby on Rails that you have an issue with, or is it Model View Controller in general?
I think MVC in general can be a very good way to approach designing some things, but as with all software development patterns it has pros and cons. One of the cons is that it's a relatively complex design pattern, so it can be difficult to get into it.
Is there a specific aspect to it that you find problematic? I'd be happy to help explain.
I had already asked this question on the Russian StackOverflow, but so far I haven't got any real answers. My main question is:
Why do we need
SELECT /* … */ FOR UPDATEin PostgreSQL?The documentation clearly says:
My understanding is that if I do something like this in transaction:
Then do something with the data in the application and then do:
Then I'll get the expected result. That is, all rows with the required IDs will be updated, regardless of what other transactions might have been doing with those rows. But, since
SELECT /* … */ FOR UPDATEexists, this isn't that simple, is it?When do I absolutely need to use
SELECT /* … */ FOR UPDATE?Does the transaction isolation level affect this? Do I still need
SELECT /* … */ FOR UPDATEwhen I useSERIALIZABLE?