Default value for hstore column

[sxua]

It would be nice to set default value as an empty array with hstore(array[]::varchar[]). In that case you can smoothly use store_accessor, which is really cool.

[diogob]

It does not seem a good practice database wise. What do you mean with smoothly use store_acessor? To be quite frank, I've never tried to use store_acessor with a hstore column.

[sxua]

store_accessor works just fine with hstore column (read-only). And about default, I mean ability to setup column like this: t.hstore :data, default: [] or something else.

[diogob]

Do you mean t.hstore :data, default: {} ? Using an empty array instead of a hash does not seems a consistent behavior.

[sxua]

Yeah, hash, not array.

[diogob]

Yeah, it would be nice indeed, I'll take a look into it.

[amacneil]

Related to this, would it be possible for the default to always return an empty hash, rather than nil?

Currently it's hard to call things like row.data["key"], because if there are no keys it throws undefined method `[]' for nil:NilClass

Let me know if I'm missing something here :)

[sxua]

For now you can use default value in database, adding this to your migration:
execute("ALTER TABLE your_table ALTER COLUMN data SET DEFAULT hstore(array[]::varchar[])")

[chrisvariety]

+1 this would be great to have. I am looking to be able to do

Page.new.data[:test] = 'abc123'

without it blowing up about .data being nil by default.

I tried the ALTER TABLE... but it didn't seem to work.

[alhafoudh]

+1

[mohangk]

+1

[chancancode]

@adrianmacneil I agree the ability to set a default column value in the migration would be nice to have, but I would not make that the "default" behaviour of the gem. NULL and {} are two different things.

[amacneil]

I'm aware NULL and {} are different things, but I don't think NULL is a very useful default (because as mentioned above it throws an exception if you try to access a key, so you would always need to test the nil case before accessing the hash). At least being able to specify the default in a migration would work around this though. But it would be nice if this gem could handle a NULL database value and still allow writing to the hash without testing for nil first.

[chancancode]

As I mention in #25, I see activerecord-postgres-hstore's role as library that provides lowest-level access (next to writing raw SQL) to HStore in ActiveRecord, so people could build useful stuff on top of it. It should expose all the available features that HStore exposes, and one of these features is the ability to assign NULL as the value for a key. This should take precedence over any connivence/sugar/abstraction that the gem may choose to provide (i.e. any "fix" for this "problem" should not break the ability to assign NULL to a key).

t.hstore :data, default: {} seems to be a good compromise. Or you could also do it at the active record level and initialize the value with an after_initialize callback.

[diogob]

@chancancode I was thinking about the explicit default usage inside the migration. But sincerely I do not have the time to work on this now. If someone want to make a pull request with this behaviour though...
I'll leave the issue open.