The "is_" prefix and boolean fields in a database in Elixir/Ecto

Questions / Help
1

The prefix “is_” is reserved for macroses and the “?” should be used for function names which return a boolean:

# wrong
def is_good(x), do: true

# right
def good?(x), do: true

It’s a recommendation, yes.

However, my question: how about the boolean fields in a database which titled as “is_aaabbcc”? I name them with “is_” because in a database I always do this with boolean fields. Then how would I go about that in Phoenix/Ecto?

schema "some_table" do
  field :is_this_good, :boolean

There’s no support for naming it “this_good?”, right? Ecto doesn’t support that – a field must have the exact same name in a database and in a model, correct?

How should I deal with this?

2

The prefix is_ is not for macros in general, it is for guardsafe predicates. But of course you are right, it is a recommondation.

Fieldnames in structs aren’t influenced by this rule in any way, since you can’t access a structs or maps fields in a guard anyway.

And since `:this_good? is a valid atom, I do not see why you shouldn’t be able to use it as a fieldname…

iex(1)> foo = %{bar?: :baz}
%{bar?: :baz}
iex(2)> foo.bar?
:baz
3

Ecto doesn’t support that – a field must have the exact same name in a database and in a model,

4

Only until the next ecto version is released: https://github.com/elixir-ecto/ecto/releases/tag/2.2.0-rc.0

1 Like
5

So, when your tabe doesn’t end on ? I do not see your actual problem…

Or do you want to have a column :is_foo? It’s even less a problem… As I said, thats a rule for predicates, not for fields in structs/maps.

1 Like
6

re-read my question.

7

Since 2.2 that was released 4 days ago ecto does support renaming fields:

schema "foo" do
  field :good?, :boolean, source: :is_good
end
3 Likes
8

I showed you that :this_good? is not a problem, I told you as well that is_this_good is not a problem as well…

But maybe you wanted aliasing column names, which I am not a fan of… It makes things easier at first, but more complicated after everything has outgrown a certain size…

I had a lot of trouble to map faulty queries in the SQL log to actual code, because of those aliasing.

9

Uhh, I have an ancient oracle database that prepends every-single-tablename to every-single-fieldname. It is MUCH nice to refer to spbblh.id instead of spbblh.spbblh_id! And I have multiple hundreds (maybe over a thousand) of these columns that I have to talk with across multiple dozens of tables. o.O…

Believe me, it does not make things more complicated at a certain size as I doubt anyone in Elixir-land anywhere talks with a database as old or as massive as I do. It helps, a lot!

10

Okay that’s definitively a point for you. But in that legacy stuff I had to deal with the aliasing was without much sense. In the database I had a column ‘gehalt’ (German for salary, some people say Lohn as well) but it was aliases to ‘loan’ in the code…

The actual names were from a different domain, but all aliases were from German column and table names to more or less bad translated English words in code… The above is just an example from a domain most people do understand without further explanation

So do we want to agree on aliasing is a toll which rises or falls depending on the policies applied to it?

11

Eh maybe useful to english speakers but that is not a change I’d make. I keep the field names in mine (and a lot are entirely nonsensical things like spriden_sprinfaddr unless you know the weird acronyms in use, but I just remove the prepended table name is all. :slight_smile: