Null = true rails

We will need some pre-generated data to work with and render to our page. We generated our Rails API. It will add many files to our project.

It will add a lot of files that will help run our project. To add the gem, run the following line in your console followed by the generator.

A Rails generator is used for automating the process of creating files with boilerplate code. It creates and updates files based on templates, etc. This is where it declares where all the queries should go and set up mutations. The generator is very helpful here! It is mounting graphiql::Rails::Engine for us. This allows us to test queries and mutation using the handy web interface, GraphiQL.

Think of it as building out documentation and a fun place to test out your queries on the web. Alternatively, you can use the Apollo Studio Explorer. Notice the new items method added here. The description is optional but good to have since it helps with documentation. In your console, enter the following command. You might be thinking, how does this all work? It looks for the method with the same name defined in the class time thanks rails magic!

We now have enough code to start your rails server. In GraphiQL run the following query. It is where requests are sent to. The text was updated successfully, but these errors were encountered:. I hope this is not me being too sleepy this morning Sorry, something went wrong. The null: false was added in The generator will still respect the Rails. Thank so much you for pointing out the origin, the rationale and the discussion. It is very helpful.

In most cases, most associations, I do want the association required by default, so I follow the usual convention. And in my use case, I did edit the migration. It is not really a problem at all for me, but it did surprise me a bit.

The question is when you have two existing tables with data records , and you want to create an optional association the "Add Columns To Table" generator. If null is not allowed by the constraint, and no other default value is offered, the database would not have a way to decide.

If you know for sure that you had, for example and user with id: 1 , you could do something like this, to set all existing records to belong to that user by default:. I understand that in many cases you do know the associations you want to build before any data is added to the tables, so this won't be a problem In my case new requirements were added after the fact. Still, this is a just a matter of choice, and I am ok with the decision if the general sentiment is that it is not important.

As louim noted, this is behavior is intentional so I'm going to close this. Hi Rails folks, I have to say, this feels like there is a bug somewhere but I suppose it's a matter of perspective. Your suggested query is wrong - only where x: [nil, false] accomplishes what where. As I see it Rails is providing a faulty abstraction here. MySQL has no such thing as booleans.

If Rails wants me to believe which is a good thing that my column is of boolean type, then it should ensure that a "not-true" query yields whatever is not true.

Exactly this. It's nothing. And while nothing is different than true, NULL still doesn't match. I've run into this myself on more than one occasion. Rails has little to do with this, because it simple translates to valid SQL. For example, consider the question "How many books does Juan own? By the way, this happens in PostgreSQL as well, probably as with any other relational database. I guess a solution is to modify the schema to avoid NULL values, if possible default: false, null: false.

Otherwise it leads to some inconsistencies like:. If I write. The above discussion both confirms that the behaviour is intended, and explains why that is the chosen intended behaviour. It's also been true since where. This query will return null values as expected as they are distinct from the value passed.

I just stumbled over this too. The Rails way is correct in this case. Even if you do:. Couldn't agree with feliperaul more here.