about the enum, do you have a stack trace?
or is it a compilation error?
or the query and entity field
s/or/of
btw, about the fk: i think it is possible to set the db constraint to be DEFERRED
if the issue is really a circular dependency
object Status extends Enumeration {
case class Status(name: String) extends Val(name)
val ACTIVE = AccountStatus("active")
val INACTIVE = AccountStatus("inactive")
}
class Foo(name: String, status: Status.Status) extends Entity
SlickQuery[Foo].filter(_.status.col === Status.ACTIVE)
I think it might have to do with whatever implicit mappers Slick is using to convert the value to a Column?
but i don’t remember what this means :(
maybe you can provide the implicit by using MappedColumnType.base
this is the way that the TypedType is provided for entities ^
I think I found a solution to the slick enum issue. I'm running into problems with the Val enums used for Activate though. My enumerations are failing comparisons. The indexes on values that should be equivalent (they have the same name) are different. Also when I inspect the vmap of the outerEnum there are duplicates.
Ok, I finally realized what was going on with the enums. I think this may be a serious flaw with the use of Enumerations in activate.
object Status extends Enumeration {
case class Status(name: String) extends Val(name)
val ACTIVE = Status("active")
val INACTIVE = Status("inactive")
}
val a = Status.ACTIVE
val b = Status.Status("active")
val c = a == b // false
val d = a.name == b.name // true
c is true for running this code
let me test the code again
@spry-rproud index for the fks?
I have run my migration and have 0 indexes in the db.
I'm just wondering if I need to explicitly create them in the migration.
for fks, it is necessary to create “manually"
i couldn’t reproduce
There's also no protection from anyone doing the same thing in code.
Which given the definition of the Enumeration they are free to do.
or in this case it deserializes as a common class?
using enum.withName