Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Flavio W. Brasil
    @fwbrasil
    It works normally, so I would need a reproducible case to verify if it is a bug
    The only case that activate can't order is where when there is a circular reference. Could that be your case?
    About the nested properties with slick, it is necessary to do the joins explicitly
    So join with the B entity and then filter it
    It is more boilerplate, but I think it is the only alternative that slick supports
    Ryan Proud
    @spry-rproud
    For the fk issue the entities are defined like the following, so not strictly circular but there is a circular reference through foos.
    class Foo(val a: String, val bar: Bar) extends Entity
    class Bar(val name: String) extends Entity {
      def foos = selec[Foo].where(_.bar :== this)
    }
    Ryan Proud
    @spry-rproud
    It doesn't seem like SlickQuery plays nice with Enumerations. Is there a workaround? I get the Value col is not a member of errors.
    Flavio W. Brasil
    @fwbrasil
    @spry-rproud what is the database you are using? most of the databases don’t support the creation of rows that have a circular dependency in the same transaction
    Ryan Proud
    @spry-rproud
    Postgresql
    But it's not truly a circular relationship is it? Bar doesn't reference Foo.
    Flavio W. Brasil
    @fwbrasil
    let me check the code again
    yeah, there isn’t a circular dependency
    you said that it isn’t possible to reproduce easly, right?
    Ryan Proud
    @spry-rproud
    No. When it comes up again I will try and determine a better root cause.
    Any input on the SlickQuery Enumeration issue?
    Flavio W. Brasil
    @fwbrasil
    k, because i’m clueless about what could be the issue
    about the enum, do you have a stack trace?
    or is it a compilation error?
    Ryan Proud
    @spry-rproud
    It's a compile error. Value col is not a member of
    Flavio W. Brasil
    @fwbrasil
    could you share a code snippet?
    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
    Ryan Proud
    @spry-rproud
    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?
    Flavio W. Brasil
    @fwbrasil
    yep, i think it can’t find a TypedType
    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 ^
    Ryan Proud
    @spry-rproud
    Ok, I'll look into it. Thanks.
    Flavio W. Brasil
    @fwbrasil
    y’re welcome, maybe try to find slick examples using enums
    Ryan Proud
    @spry-rproud
    Ok
    Ryan Proud
    @spry-rproud
    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.
    Ryan Proud
    @spry-rproud
    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
    Flavio W. Brasil
    @fwbrasil
    @spry-rproud being a case class Status should return true if two instances have the same name
    c is true for running this code
    Ryan Proud
    @spry-rproud
    It's not because Status also has an index which is not equivalent
    Flavio W. Brasil
    @fwbrasil
    but if the vmap has multiple instances with the same name there is indeed something wrong
    let me test the code again
    Ryan Proud
    @spry-rproud
    Also is it expected behaviour for postgresql not to create implicit indexes when creating tables via Migrations?
    Flavio W. Brasil
    @fwbrasil
    @spry-rproud could you describe again the issue with enumerations? i did some tests, but couldn’t reproduce
    @spry-rproud index for the fks?
    Ryan Proud
    @spry-rproud
    both PK and FK
    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.
    Flavio W. Brasil
    @fwbrasil
    i think it the db already creates indexes for primary keys
    for fks, it is necessary to create “manually"