fwbrasil/activate

Pluggable object persistence in Scala

Ryan Proud

@spry-rproud

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

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?

Ryan Proud

@spry-rproud

https://github.com/json4s/json4s/blob/5e301ef63b345f694898ab553244556e7df9d9c6/ext/src/main/scala/org/json4s/ext/EnumSerializer.scala#L46-L60

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

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

https://github.com/fwbrasil/activate/blob/a29e704a06b7f8dbba0aba7b6dd014c155b5d95f/activate-test/src/test/scala/net/fwbrasil/activate/ActivateTestContext.scala#L960

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.

Flavio W. Brasil

@fwbrasil

if you use byId[Bar](barId, initialized = false) activate doesn’t touch the database

Ryan Proud

@spry-rproud

Ok, thanks. That sounds like what I'm looking for.

Where communities thrive

People

Repo info

Activity