[2.0] New Plugin MongoDB / Salat

[Leon Radley]

Hade some free time, created a plugin for working with mongodb.

https://github.com/leon/play-mongodb

Since I havent got my own maven repo I need to be able to publish it somewhere.

I've signed up for a sonatype repo, so lets hope it comes through soon.

until then, you can checkout the repo and do a compile and a publish-local.

the sample is setup to go for the local directory, but you will need to change the path in your `project/Build.scala` to point to your `~/.sbt/local` since SBT doesn't seem to like relative paths.

you also need to install and run mongo

`brew install mongodb`

and then start it with

`mongod`

A Question for the core developers.

If we (the community) want to create plugins and share with the rest of you, it's quite hard to get the stuff out there.

Signing up for a sonatype oss account, gpg signing, custom sbt settings... the list is long to simply share something which should be as simple as sharing a github link.

What could we do to simplify this?

[Julien Richard-Foy]

Can you please point out the difference with the other MongoDB plugin
that was released a few weeks ago?

BTW you can deploy your own maven repository for free on your github pages.

Regards,
Julien

[peter hausel]

On Tuesday, April 10, 2012 9:32:24 AM UTC-4, Julien Richard-Foy wrote:

Can you please point out the difference with the other MongoDB plugin
that was released a few weeks ago?

The other plugin is using a different mongo JVM driver.

[peter hausel]

that looks good, just one question about the README: should not you register the plugin in play.plugins file?

[Stéphane Godbillon]

Well, it's not exactly true: it uses a different mapper for
serializing/deserializing objects; the driver is actually the same
(the official java driver from 10gen).
--
Stephane Godbillon

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/M9RhQVecczgJ.
>
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framewor...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.

[peter hausel]

true, I meant more like the high level wrappers and the languages (salat+casbah is using scala, while mongo-jackson is preferred by the java community) - the underlying driver is in fact the same (ie the java one).

On Tuesday, April 10, 2012 9:52:26 AM UTC-4, Stephane Godbillon wrote:

Well, it's not exactly true: it uses a different mapper for
serializing/deserializing objects; the driver is actually the same
(the official java driver from 10gen).
--
Stephane Godbillon

On Tue, Apr 10, 2012 at 3:42 PM, peter hausel <peter....@gmail.com> wrote:
>
>
> On Tuesday, April 10, 2012 9:32:24 AM UTC-4, Julien Richard-Foy wrote:
>>
>> Can you please point out the difference with the other MongoDB plugin
>> that was released a few weeks ago?
>
>
> The other plugin is using a different mongo JVM driver.
>
>>
>> BTW you can deploy your own maven repository for free on your github
>> pages.
>>
>> Regards,
>> Julien
>
> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/play-framework/-/M9RhQVecczgJ.
>

> To post to this group, send email to play-framework@googlegroups.com.

> To unsubscribe from this group, send email to

> play-framework+unsubscribe@googlegroups.com.

[Leon Radley]

The README is updated with some new stuff :)

I also got access to the open source repo over at sonatype which is automatically mirrored with repo1.maven.org, though I don't know if they mirror snapshots?!

If so I could completely remove the setup section of having to add your own resolver.

technically this could be the "main" mongo plugin, since most if it is about handling the configuration.

So we could have different mappers on the same core. What do you guys think?

any suggestions on how this could be done?

[Paulo "JCranky" Siqueira]

Quick 2 cents about maven central: please do it (as you are already trying). Having to add new resolvers is always a pain in the neck.

[]s,

Paulo "JCranky" Siqueira
http://jcranky.com

Em 10/04/2012 14:27, "Leon Radley" <le...@radley.se> escreveu:

[Wes Freeman]

Thanks for putting this plugin together, Leon. It's working great for me so far, on my first play 2 prototype app. Great timing...

Wes

[Leon Radley]

I've decided to rename this plugin to salat and simplify it a bit. At first I thought I'd make a general scala mongodb plugin and have salat live beside it.

Most of the plugin is about handling multiple sources and configuration.

But it only meant you hade to add more imports and the "YAGNI"(you ain't gonna need it) was a fact. I arrived at the conclusion that:

From now on this plugin is going to be the Salat plugin.

I've also added query string and path binders for ObjectId, add the implicit conversions to you Build.scala settings.

val main = PlayProject(appName, appVersion, appDependencies, mainLang = SCALA).settings(

  resolvers += "OSS Repo" at "https://oss.sonatype.org/content/repositories/snapshots",

  routesImport ++= Seq("se.radley.plugin.salat.Binders._")

)

The new home is http://github.com/leon/play-salat

[Leon Radley]

I've submitted version 1.0 to maven central, just need to get approved by sonatype before they start syncing my stuff to central :)

[Leon Radley]

It seems that repo.typesafe.com is mirroring the sonatype repo, so it's already working!

[Wes Freeman]

I agree, play-salat makes more sense. It leaves room for other mongodb plugins which use other mappers.  

I did run into an issue yesterday while trying to pass lists to views:
http://stackoverflow.com/questions/10132730/play-framework-2-0-scala-classcastexception-models-mymodel-cannot-be-cast-to

Was I doing something else wrong, or do you really need to have different names for the object and the case class?

Wes

--

You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/mBGb0I8sRboJ.

To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.

[Leon Radley]

I replied on stack overfow. but I'll say the same here for future reference.

scala doesn't seem to like extend the companion object of the entities, so we need to have them in a separate object.

I've been working on a project all day with the plugin, and seems to be holding up good.

The plugin is now available from the main repo which means we don't have to add to the resolvers which is nice, and i've also added some other nice stuff.

Check out the updated tutorial!

:)

On Friday, April 13, 2012 4:22:15 PM UTC+2, Wes Freeman wrote:

I agree, play-salat makes more sense. It leaves room for other mongodb plugins which use other mappers.  

I did run into an issue yesterday while trying to pass lists to views:
http://stackoverflow.com/questions/10132730/play-framework-2-0-scala-classcastexception-models-mymodel-cannot-be-cast-to

Was I doing something else wrong, or do you really need to have different names for the object and the case class?

Wes

[Wes Freeman]

I still get this error, every time I edit the view. I need to restart play for it to start working again. Weird.

play.core.ActionInvoker$$anonfun$receive$1$$anon$1: Execution exception [[ClassCastException: models.Applicant cannot be cast to models.Applicant]]

at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:82) [play_2.9.1.jar:2.0]

at play.core.ActionInvoker$$anonfun$receive$1.apply(Invoker.scala:63) [play_2.9.1.jar:2.0]

at akka.actor.Actor$class.apply(Actor.scala:290) [akka-actor.jar:2.0]

at play.core.ActionInvoker.apply(Invoker.scala:61) [play_2.9.1.jar:2.0]

at akka.actor.ActorCell.invoke(ActorCell.scala:617) [akka-actor.jar:2.0]

at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:179) [akka-actor.jar:2.0]

Caused by: java.lang.ClassCastException: models.Applicant cannot be cast to models.Applicant

at views.html.Applicants.search$$anonfun$apply$1.apply(search.template.scala:30) ~[classes/:na]

at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194) ~[scala-library.jar:0.11.2]

at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:194) ~[scala-library.jar:0.11.2]

at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:59) ~[scala-library.jar:0.11.2]

at scala.collection.immutable.List.foreach(List.scala:45) ~[scala-library.jar:0.11.2]

at scala.collection.TraversableLike$class.map(TraversableLike.scala:194) ~[scala-library.jar:0.11.2]

Wes

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/0aP7K-ZP6R4J.

[Marius Soutier]

I have seen a similar problem. I logged the error with the Salat guys, but the only thing that helped so far was to disable Play evolutions in the config file. It didn't completely eliminate the problem, it only made it very rare.

Do you use inheritance in your models?

https://github.com/novus/salat/issues/32

---
Marius Soutier
http://www.linkedin.com/in/mariussoutier
http://xing.to/mariussoutier

[Wes Freeman]

By inheritance do you mean models that extend a base class? No.

It looks like you already saw my post on stackoverflow mentioned earlier in this thread--that's basically how I'm using it. I changed it to have DAO in the DAO object names, so I no longer have the companion object holding my custom query functions, etc.

I am using enumerations (with the salat enum strategy: @EnumAs(strategy = EnumStrategy.BY_VALUE))  for some of my fields, but I don't see how that would be related to this. Other than that it's pretty clean, a few Lists of primitives or ObjejctIds, some Float fields, some Strings.

Glad to hear someone else has similar issues (at least that means I'm not alone, ha)--I do notice that mine has the exact same name for the cast exception, and yours is slightly different.

I'll follow that issue on github--hopefully we can figure it out. It's workable as it is, just a bit slower to have to reload play every time I make a minor change to a view.

Wes

[Leon Radley]

It's something to do with the class loader not releasing the old objects.
I got a tip that I should add a call to ctx.clearAllGraters when we
restart. But that's been in there since v1.0.

It's very annoying :(

[Marius Soutier]

We've been haunted by this problem since the beginning of our project. We never figured out what influenced its occurrence, only evolutionplugin=disabled helped a bit. And for us it's only the classes that inherit from a trait or abstract class. It's also hard to reproduce in a simpler project. We don't use enums in the case classes (how do you map them to your forms?).

Hopefully it can be fixed, otherwise we'd have to switch to Casbah or the other MongoDB plug-in.

- Marius

---
Marius Soutier
http://www.linkedin.com/in/mariussoutier
http://xing.to/mariussoutier

[Wes Freeman]

Does this happen when you run in production mode? I am guessing that it won't, but it would be good to confirm. It's really only a nuisance while developing, as it's easy to restart play when you edit a view--I've gotten into the two step habit now.

In my form I'm using just a plain tuple--haven't figured out how the bind and fold works for validation yet (wish there were some more examples in the documentation). Then I map it to the object with <Enum>.withName. Probably not the cleanest in the form POST handling, but at least it lets me use enums. I'm sure there's a better way... (feel free to point it out, if someone knows of one)

Wes

[Marius Soutier]

No I haven't seen in production (yet). But IMHO it's more than a nuisance, IMHO it renders Play + Salat unusable.

I had tried to use Enumerations with `mapping()`, and it didn't work.

---
Marius Soutier
http://www.linkedin.com/in/mariussoutier
http://xing.to/mariussoutier

[Wes Freeman]

I wonder how morphia would behave working with Scala models in play. Has anyone given it a try? I enjoyed using it in Java--wanted to give Salat a chance though. I'll probably give it a bit more time to see if something improves in the play class loader or salat, or whatever is causing this--this is just a prototype for me, anyway.

I'm not using mapping, just:

... Form(   

      tuple ( 

       ...

       "enumField" -> nonEmptyText

      )

    )

It's ugly in the handling code, since it can't map directly to the class, which does:

val formTuple = form.bindFromRequest.get

Then I build the object with the constructor before saving, using (this is the ugly part):

enumField = Enum.withName(formTuple._5)

Anyway, that's the only ugliness (in the controller)--it's much nicer to use enums everywhere else, especially in view forms and query logic.

[Nuanda]

Leon what do you think about defining the plethora of model case
classes that you can end up with, within Objects?

We found that we have lots of model objects lying around due to nested
J/BSON structures, which if you are using one model package makes for
annoying namespace clashes. Thought to encapsulate the nested model
definitions in a companion object of the root model class, but this
seems to blow up during runtime deserialization...?

http://stackoverflow.com/questions/10281685/can-i-manage-the-scope-of-salat-case-class-dtos-by-using-a-companion-object

Many Thanks,

Nuanda

[Leon Radley]

Hi!

As you might have seen, Rose Toomey has been busy with salat trying to get past the strange classloader problems that have been haunting us.

He's built a new ModelCompanion which seems to  have fixed the problem in the early tests I've done.

I'm looking into changing the play-salat plugin to utilize this new trait, or rather let you decide.

I don't know your problems will go away when using the ModelCompanion instead, but I think it's worth a try.

I'll post here as soon as I've pushed the 1.0.2 release to the repo, and you can give it a try.

[Leon Radley]

I've just pushed v1.0.2

The API for the plugin has changed a bit. and we now thanks to Rose Toomey have a ModelCompanion with some nice extensions on it.

To get your code up to date, check out the updated README and sample over at github <https://github.com/leon/play-salat>

[Wes Freeman]

Thanks Leon and Rose!

Looks like it solved the play restart issue--only took 30 minutes to migrate my code to the new API.

Wes

--

You received this message because you are subscribed to the Google Groups "play-framework" group.

To view this discussion on the web visit https://groups.google.com/d/msg/play-framework/-/7pZ0u4A_Lh4J.

[Fabien Pennequin]

Hi!

I try to use this plugin but the compilation of my project always
fails. I get the same error with the sample project (https://
github.com/leon/play-salat/tree/master/sample).

[error] /path/to/play-salat/sample/target/scala-2.9.1/src_managed/main/
routes_routing.scala:14: object creation impossible, since:
[error] method prefix in trait Routes of type => String is not defined
[error] method setPrefix in trait Routes of type (prefix: String)Unit
is not defined
[error] object Routes extends Router.Routes {
[error] ^
[error] one error found
[error] {file:/path/to/play-salat/sample/}sample/compile:compile:
Compilation failed