Caching inverseMany values

23 views
Skip to first unread message

Friggles

unread,
Nov 14, 2012, 6:08:43 AM11/14/12
to circumfl...@googlegroups.com
I'm getting some caching when I fetch inverseMany relations

I have:
class User extends Record[Long, User] with IdentityGenerator[Long, User] {
  val id = "id".BIGINT.NOT_NULL.AUTO_INCREMENT

  def comments = inverseMany(Comment.owner)
  def devices = inverseMany(Device.owner)
  def documents = inverseMany(Document.owner)

  def PRIMARY_KEY = id
  def relation = User
}

and corresponding Device, Document, Comment  classes with

lazy val owner = "owner_id".BIGINT.REFERENCES(User).ON_DELETE(CASCADE)

When I run this code:

Context.executeInNew { ctx =>
   val u = User.find(1);
      Logger.info("" + u.documents.item.size) // should be 4
      Logger.info("" + u.devices.item.size) // should be 1
     
      Logger.info("" + u.comments.get.size) // should be 0
    }

I get
4
4
4

Whichever item is first seems to cache.

Also if i try u.documents.get.map(d => ...)
and then u.devices.get.map(d => ...) i get a
ClassCastException: models.Document cannot be cast to models.Device at run time (again, whichever relationship runs first seems to cache.

wrapping each statement in its own Context.executeInNew { ctx => ...} fixes it, but should this be the case or am I missing something obvious?

Any help would be much appreciated.

Boris Okunskiy

unread,
Nov 14, 2012, 2:59:25 PM11/14/12
to circumfl...@googlegroups.com
Warm greetings, Friggles,

Now, frankly, when I first read your letter I've been like "OMG! Does that thing really happens with our ORM?"
I then immediately went to see the sources myself -- and guess what? You are absolutely right, it is totally a bug. Our bug.

I think the reason we overlooked this issue is that we do not like inverseMany much (you know, because they aren't real queries after all, with the lack of alll the ORDER BY, WHERE and LIMIT things). Good thing is that I am ready to fix this in the latest Circumflex snapshots ASAP.

Many thanks for reporting this valuable issue!

Best regards,
Boris Okunskiy
Chief Software Architect
EduArea LLC / SAVANT.PRO

Boris Okunskiy

unread,
Nov 15, 2012, 1:32:05 AM11/15/12
to circumfl...@googlegroups.com
Okay, the problem was rather simple: we just used weak cache keys. 


Many thanks for reporting the issue.

Best regards,
Boris Okunskiy
Chief Software Architect
EduArea LLC / SAVANT.PRO

-- Soit le meilleur dans ce que tu feras.

Friggles

unread,
Nov 18, 2012, 4:03:57 AM11/18/12
to circumfl...@googlegroups.com
Hi Boris,

The latest snapshot has corrected the problem. I've since been using a custom fetch query as you've suggested, but its good to know its available for smaller simple relations.

Thank you for your prompt response and fix.
Reply all
Reply to author
Forward
0 new messages