SalatDAO should support polymorphic collections about salat HOT 15 CLOSED

Salat does support polymorphic collections. Please update to the latest snapshot, try again and include the text of your compiler error?

from salat.

Oh right. You want to type ChildCollection to an abstract superclass.

We've gone back and forth on allowing that due to its runtime reflection requirement. I'll change the typing and write some specs this weekend, but you should be aware that it will not be as fast as a DAO typed to a concrete class. Will the speed make a difference to your project? Most likely not, but under very heavy usage everything counts, which was our original design intent in not putting it in...

I'll let you know when an updated snapshot is up for you to try.

(Also, Role should have its own _id field, in addition to the "parent id" field - although MongoDB Java driver will insert an ObjectId for you if no _id field exists, it is best practice to add one yourself, and has the side benefit of making child collection "by id" methods work.)

from salat.

Cool thanks, looking forward to it.

So your advice would be not to use SalatDAO for polymorphic collections in performance-critical code?

from salat.

Well, for everyday usage it's probably fine. To give you more
background on why Salat was developed, I work at a financial startup
where we do realtime analytics that can require large datasets. In
this case, the time I spend deserializing my data back into my domain
model before I begin doing the calculations is sheer overhead. So I
wouldn't use ProxyGrater under those circumstances.

But we have been moving more toward providing the polymorphism support
people want, because in many use cases the convenience outweighs the
runtime hit - you can see ProxyGrater to get an idea of the added
cost. Grater just serializes and deserializes: done. But ProxyGrater
needs to look up a concrete instance of Grater based on the type of
the incoming/outgoing object, which adds a small continuous cost. If
you're interested, compare the asObject and asDBObject methods in
ProxyGrater and ConcreteGrater:
https://github.com/novus/salat/blob/master/salat-core/src/main/scala/com/novus/salat/ProxyGrater.scala
https://github.com/novus/salat/blob/master/salat-core/src/main/scala/com/novus/salat/Grater.scala

I suggest trying out the child collection typed to Role, and if the
performance is not good enough, consider making Role a case class and
using a sealed abstract class/trait and case object hierarchy to
distinguish different types of role.

I'll have a new snapshot for you tomorrow.

On 21 January 2012 19:22, Marius Soutier
[email protected]
wrote:

Cool thanks, looking forward to it.

So your advice would be not to use SalatDAO for polymorphic collections in performance-critical code?

---

Reply to this email directly or view it on GitHub:
https://github.com/novus/salat/issues/27#issuecomment-3600149

from salat.

Thanks, I'll definitely check it out. I guess for user management I don't need extra performance. But there's also one area in my app where database-object-mapping-performance will matter, so I'll dive into it.

My other big concern so far is the tight coupling between my model classes and the MongoDB classes. But in the end that's just the same problem with relational modeling.

from salat.

Also, Role should have its own _id field, in addition to the "parent id" field - although MongoDB Java driver will insert an ObjectId for you if no _id field exists, it is best practice to add one yourself, and has the side benefit of making child collection "by id" methods work

Somehow, this doesn't work. The resulting child collection doesn't have any id at all.
I get something like this:

{ "_id" : { "$oid" : "4f1c63df0364894c96ac18c2" }, "_typeHint" : "models.User", "username" : "[email protected]", "password" : "sdsdf", "email" : "[email protected]", 
  "roles" : [ { "_typeHint" : "models.AdminRole", "someInfo" : "hi" } ], "gender" : 1 }

I added the id directly to the role:

@Salat sealed abstract class Role(profileid: ObjectId = new ObjectId)
case class AdminRole(someInfo: String) extends Role

from salat.

Hi Marius, your snapshot is now available for testing. After running sbt update and your original code should compile without type errors now. Let me know how that works for you.

See novus@9553d12 for details.

The reason why you are not seeing _id in Role above is that it is not actually added until you insert it into the MongoDB collection - this is not done by Salat, nor Casbah, but rather deep in the guts of mongo-java-driver.

from salat.

Unfortunately it's not in the snapshot. The date in http://repo.novus.com/snapshots/ is at 29-Nov-2011.

The reason why you are not seeing _id in Role above is that it is not actually added until you insert it into the MongoDB collection

The BSON from above is from the database. I saved it, but the id from the abstract class is missing.

from salat.

I published 2.8.1 and 2.9.1 - which snapshot are you using?
On Jan 24, 2012 7:19 AM, "Marius Soutier" <
[email protected]>
wrote:

Unfortunately it's not in the snapshot. The date in
http://repo.novus.com/snapshots/ is at 29-Nov-2011.

The reason why you are not seeing _id in Role above is that it is not
actually added until you insert it into the MongoDB collection

The BSON from above is from the database. I saved it, but the id from the
abstract class is missing.

---

Reply to this email directly or view it on GitHub:
https://github.com/novus/salat/issues/27#issuecomment-3631383

from salat.

http://repo.novus.com/snapshots/com/novus/salat-core_2.9.1/0.0.8-SNAPSHOT/ - this shows a timestamp of 23 January for the 2.9.1 snapshot.

from salat.

Ok, it looks like you are using the 2.9.0-1 snapshot. Please use 2.9.1 instead.

from salat.

Ok I used the wrong one (2.9.0_1). Everything works now, thank you.

from salat.

Here's a gist that shows what I mean when I say the mongo-java-driver will add an _id field if you don't do it yourself:

https://gist.github.com/1670017

from salat.

Glad to hear everything is working!

from salat.

Thanks for the gist. My problem was that Mongo didn't generate any _id for an embedded document (I originally tried to embed the role, because without the user it doesn't make much sense). With the separate collection, the id is generated, and I also added it -as you advised- to the abstract class (had to be a val to be recognized).

Thanks for your quick support, much appreciated!

from salat.