Development for v3

[lwe]

trafficstars

• [x] Enums should be symbols, see #100
• [x] #fetch method for SE::Enum, see #96
• [ ] Helper methods for queries, see #95

Any other wishes? Also feel free to try this branch and see if it fixes #100 as expected.

This is a new major version, because the change to return symbols is a breaking change.

/cc @lucke84, @matthewrudy

[lucke84]

Awesome! Can we put #95 on the table too?

[matthewrudy]

I think that including :scope as a default :with is something I'd remove

My project has

• 42 as_enum declarations
• a maximum of 50 values from one of them

It means we create a whole mess of scopes.

I created my own alternative

SimpleEnum.configure do |e|
  e.with = [:attribute, :dirty, :single_scope]
end

module SimpleEnumCustomisations

  # I want to say
  #
  #   Coupon.status_scope(:active)
  #
  def generate_enum_single_scope_methods_for(enum, accessor)
    return unless respond_to?(:where)

    name = accessor.name

    singleton_class.send(:define_method, "#{name}_scope") do |key|
      where(accessor.source => enum[key])
    end
  end
end

ActiveRecord::Base.send :extend, SimpleEnumCustomisations

if we had enum.fetch(key) I'd use that, and raise an exception trying to scope by a non-existing enum key

[lwe]

@lucke84 - added :+1: @matthewrudy mhh, yes probably makes sense to remove that by default, maybe we can merge that single scope idea with what is proposed in #95 somehow?

[hgani]

Speaking about wishes :), I am not sure if this has been discussed/decided before, but is it possible to support integration with DB-backed enums?

So instead of mapping to integers, we can map to DB's (e.g postgres) native enums.

Thanks

[lwe]

@hgani no, but this would of course be awesome - any idea how to support this?

[hgani]

@lwe I did a bit of research on this and the conclusion is that we can't use db-backed enums easily in Rails yet because they break schema.rb (http://stackoverflow.com/questions/7337411/how-to-use-enum-in-postgres-database-in-rails-3/16033077#16033077)

If one day Rails migration supports db-backed enums, then we can start thinking about how to make simple_enum compatible. I think it should be easy actually, probably just use strings instead of integers (which should already work with the current simple_enum)

[lwe]

Hey @hgani thanks a lot for the effort to check this out and to bad Rails does not support this out of the box yet!

[matthewrudy]

@hgani you should try schema plus

It does most of this stuff.

[hgani]

@lwe no worries, happy to help

@matthewrudy thanks, the gem looks promising. I'll keep an eye on it.

[scarroll32]

Great gem. Multiple select would be awesome, and especially if the selected values could be stored in a Postgres array column, rather than a join table (if strings).

See also: https://github.com/bbtfr/simple_enum-multiple https://github.com/bbtfr/simple_enum-persistence

[drewish]

As far as feature requests I'd love an accessor that's more compatible with Rails validations.

Specifically, it doesn't seem possible to have an optional enum that is validated. On assignment unknown values are either discarded or trigger argument errors (depending on the accessor) meaning that when the validator runs it can only check for a nil value. It would be nice if there was an option to choose an accessor that would at least hold a copy of the invalid value so the validator could differentiate between missing and invalid.

I'll mention that I'm still on 1.6 so this is just based on a review of the 2.0 code. It looks like it would be easier to plug this into the new code that 1.6, but I'll have to wait until we get through our rails upgrade.

[lwe]

Thanks and a good point, maybe rather tricky TBH, as it's hard to distinguish between: okay, I want the value and okay, I want to the original value...

[drewish]

Yeah definitely tricky. The two paths I can see are:

• keep a copy of the raw value that the validator could go off of
• allow the assignment of an invalid value and just assume that they won't bypass validations

But I'm not sure what issues that would cause elsewhere. For my project rather than getting hacky for one optional field I'm just going to create a new model to reference. Short term it's over kill but longer term it'll set me up for customizable options.

[aledalgrande]

Is this still a valid plan? If yes, can we split it into different PRs? Maybe the planning can be done with the Github Projects feature now that it is available.