Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    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"
    Ryan Proud
    @spry-rproud
    Ok
    Flavio W. Brasil
    @fwbrasil
    about the enums, could you open an issue with more info?
    i couldn’t reproduce
    Ryan Proud
    @spry-rproud
    If you run the above code it doesn't fail on the comparison of a and b?
    Flavio W. Brasil
    @fwbrasil
    yes, it fails
    Ryan Proud
    @spry-rproud
    So the problem is that any serializer (json4s, etc.). Just serializes the case class and creates a new instance of Status.Status. This will cause a failure comparing with anything created using Status.withName(name).
    There's also no protection from anyone doing the same thing in code.
    Flavio W. Brasil
    @fwbrasil
    i see, so the problem happens only when the entity is serialized?
    Ryan Proud
    @spry-rproud
    or if someone creates Status.Status("active")
    Which given the definition of the Enumeration they are free to do.
    Flavio W. Brasil
    @fwbrasil
    do you know how json4s deserializes enums?
    or in this case it deserializes as a common class?
    Flavio W. Brasil
    @fwbrasil
    if it is this code that is being used, it is the same way that activate does
    using enum.withName
    Ryan Proud
    @spry-rproud
    Sorry that's how they serialize a typical Enumeration, the problem is the value isn't an Enumeration it's a case class.
    I'm just saying it would be safer if Activate allowed Enumerations defined as follows. This would prevent these types of issues.
    object Status extends Enumeration {
        val ACTIVE = Value("active")
        val INACTIVE = Value("inactive")
    }
    Flavio W. Brasil
    @fwbrasil
    it would be better, but it isn’t possible
    Ryan Proud
    @spry-rproud
    Why?
    Flavio W. Brasil
    @fwbrasil
    there isn’t a way to deserialize the enum without the user specifying the enum object
    json4s requires an implicit formatter for the enum, right?
    Ryan Proud
    @spry-rproud
    Yes
    Flavio W. Brasil
    @fwbrasil
    it isn’t possible to use the same approach for activate
    because there isn’t a way to fail at compilation time
    it would be possible to fail at runtime if the enum serializer is not provided, but i’m not sure it is a good approach
    Flavio W. Brasil
    @fwbrasil
    i was thinking, does it work if you change the enum to be:
    object Status extends Enumeration {
      case class Status(name: String) extends Val(name)
      val ACTIVE: Value = Status("active")
      val INACTIVE: Value = Status("inactive")
    }
    try Value or Val
    Ryan Proud
    @spry-rproud
    No, that just makes name protected
    Flavio W. Brasil
    @fwbrasil
    k
    Ryan Proud
    @spry-rproud
    Do you know offhand what tests will test Enum serialization in activate?
    Flavio W. Brasil
    @fwbrasil
    many tests use this check
    but do you think that there is an issue using enums with activate (without json4s)?
    Ryan Proud
    @spry-rproud
    Yes, because it gives the possibility that someone could create an instance of the enum outside of the object.
    Status.Status("active") does not necessarily equal Status.withName("active")
    Flavio W. Brasil
    @fwbrasil
    makes sense, that could be a problem
    Ryan Proud
    @spry-rproud
    Is it possible to create a new Entity with a reference without retrieving the referenced entity?
    class Bar(var name: String) extends EntityWithGeneratedID[Long]
    class Foo(var a: String, var b: Bar) extends EntityWithGeneratedID[Long]
    
    val barId = 2l
    
    transactional {
        new Foo("something", lazyById[Bar](barId))
    }
    Flavio W. Brasil
    @fwbrasil
    the entities are loaded lazily by default
    could you explain further the use-case?
    Ryan Proud
    @spry-rproud
    Just trying to reduce the calls to the database. Don't want to have to do a select and insert for every new Foo.
    So if I could create a dummy Bar entity which just references the id it would be ideal.
    Flavio W. Brasil
    @fwbrasil
    byId[Bar](barId) is already lazy
    sorry, i’m wrong
    Ryan Proud
    @spry-rproud
    Lazy was bad wording by me.