I'm trying to convert a persistence layer from a plain old database (using ScalaQuery) to MongoDB, and I'm running into an odd issue. I use the Casbah driver, which is a Scala wrapper around the official MongoDB Java driver. Both the Java and Scala driver define - according to the docs and the overview of the .jar when I open it in Eclipse - a method findOneById that takes a single DBObject as parameter (with an ID in it).
However, when I try to access it, I get a missing method exception from the Scala compiler, both in Eclipse and SBT - Scala version 2.9.0-1, SBT 0.10.1.
What might cause this? Is this perhaps a known SBT / Scala compiler bug?
I just removed my entire repository so all dependencies get downloaded freshly, but this didn't fix the problems.
Are you sure that you call findOneById on a MongoCollection instance ?
Maybe it's the parameter type that is wrong, as I can see on the documentation (http://api.mongodb.org/scala/casbah/2.1.2/scaladoc/com/mongodb/casbah/MongoCollection.html), findOneById should take an Id of type AnyRef and optionnaly the fields to return.
You should try something like mongoCollection.findOneByID(1.asInstanceOf[Object]).
Regarding BBObject, it seems that it doesn't appear in the list of parameter (except as an implicit parameter useful to convert the fields that you request to a DBObject). Maybe the signature of the method changed since a previous release.
Hope this will help.
Related
There used to be a method named buildArguments() which was very useful for viewing query arguments. It seems that it was removed after the package version 9.0.0.
I was using it to print my queries to the console, so I was able to spot any mistakes. Was a new method introduced to replace buildArguments()?
When my scala-js code throws an error, I'd like to send a sensible stacktrace back to my server to put in the logs. By "sensible stacktrace" I mean something that gives the Scala methods, filenames, and line numbers rather than the transpiled javascript code.
I've made good progress by getting the source map and using the Javascript source-map library (https://github.com/mozilla/source-map) to translate each element of the stacktrace from javascript to the corresponding Scala code.
My issue: I need the column number of the javascript code that threw the error but don't see how to obtain it. Printing a StackTraceElement gives a result similar to
oat.browser.views.query.QueryRunView$.renderParamsTable$1(https://localhost:9443/assets/browser-fastopt.js:34787:188)
I need the "188" at the end of the line but don't see how to get it other than calling toString and parsing the result. Looking at the StackTraceElement code, the column number is a private variable with nothing in the API to access it.
Is there another approach to this that I'm completely overlooking? Anything built into scala-js that converts a javascript stacktrace to a Scala stacktrace?
I subsequently found the StackTraceJS library which does what I needed. I combined a ScalaJS facade for it with a facade for JSNlog to come up with a package that meets my needs pretty well. See jsnlog-facade. It logs to the browser console and/or the server, with Scala stack traces. Demo code included.
There is nothing in the public API to access the column number because this is a Java API, and Scala.js cannot add public members to Java APIs.
To work around this issue in the case of StackTraceElement, we export getColumnNumber(): Int to JavaScript. You can therefore use the following code to retrieve the column number:
def columnNumberOfStackTraceElement(ste: StackTraceElement): Int =
ste.asInstanceOf[js.Dynamic].getColumnNumber().asInstanceOf[Int]
Note that this "feature" is undocumented, and might change without notice in a future major version of Scala.js. If it disappears, it will be replaced by something reliable. In the meantime, the above should get you going.
Compiling Spark gives this compile error :
To fix I modify Utils.classIsLoadable method to just return true:
def classIsLoadable(clazz: String): Boolean = {
// Try { Class.forName(clazz, false, getContextOrSparkClassLoader) }.isSuccess
true
}
I realise this is not a good fix, but so far Spark seems to be running correctly from source. Has this compile error been experienced before and is there a fix? Will returning true suffice for now , I'm not sure what impact modifying this return value may have?
I suggest compiling Spark from the command-line using Maven or SBT instead of trying to use your IDE's compiler. Many of the core Spark developers use IntelliJ for editing Spark's source code but still use the command-line compilers, largely because it's been difficult to get the project to build correctly inside IDEs. Even if you're using an external compiler, you should still be able to benefit from IntelliJ's syntax highlighting, type checking, etc.
Here's a relevant discussion from the Spark developer mailing list: http://apache-spark-developers-list.1001551.n3.nabble.com/IntelliJ-IDEA-cannot-compile-TreeNode-scala-td7090.html
Note that Spark users should be able to use IntelliJ to compile applications that depend on Spark; this issue only affects developers who want to build Spark itself.
If you're interested in fixing the build to work with IntelliJ, I recommend opening a ticket on the Spark issue tracker.
I am trying to use Casbah, I get a strange error right in the beginning, on this line:
val mongoDB = MongoConnection("MyDatabase")
the error on MongoConenction says:
class file needed by MongoConnection is missing. reference type
MongoOptions of package com.mongodb refers to nonexisting symbol.
I do not know what to do with this. The jars that I have attached to my projects are:
casbah-commons_2.9.1-3.0.0-SNAPSHOT.jar
casbah-core_2.9.1-3.0.0-SNAPSHOT.jar
casbah-gridfs_2.9.1-3.0.0-SNAPSHOT.jar
casbah-query_2.9.1-3.0.0-SNAPSHOT.jar
casbah-util_2.9.1-3.0.0-SNAPSHOT.jar
which looks like a full setup of Casbah and I do not understand what it might be yearning for. So there is the question number one - what do I have to do to resolve this problem?
The question number two is - the Casbah tutorial says that I could import just one thing, and get the mongoConn() method, which is also not truth. The mongoConn() simply does not get found if I follow the instructions. So, how can I acheive that everythong works as in the tutorial?
I don't know the details of your setup, but it seems like you are not referencing the dependencies of the casbah-commons module.
According to the docs, those are:
mongo-java-driver, scalaj-collection, scalaj-time, JodaTime, slf4j-api
I'm experiencing some rather annoying problems with scala. The problem is, that I can compile small scala project perfectly, but when the projects are bigger, the compiler crashes with an StackOverflowException.
Clearly, I have to increase the stack size for the compiler, however, that's probably my main problem here, I don't know how.
I'm starting netbeans with these parameters:
netbeans_default_options="-J-client -J-Xmx512m -J-Xss8m -J-Xms512m -J-XX:PermSize=128m -J-XX:MaxPermSize=512m -J-Dapple.laf.useScreenMenuBar=true -J-Dapple.awt.graphics.UseQuartz=true -J-Dsun.java2d.noddraw=true"
So, as far as I'm aware, -J-Xss8m should increase the thread stack size to 8 mb. However, that doesn't seem to affect the compiler. So I tried to pass the same parameter to the compiler directly, using the compiler flags, which I can set in netbeans, resulting in this:
-deprecation -J-Xss8m
But again, that doesn't help, I'm still getting the exception. I searched through the netbeans documentation, but all I found was the netbeans startup parameters, which I had already set. I hope somebody here can give me further information on how to handle this problem.
Further information:
So, after a day I finally had the chance to try everything out on a different machine. I used the same settings and same compiler, but to my surprise, I didn't get the same result. Meaning, on his machine the compiler compiles the whole code without any exception.
The only difference between mine computer and his is, that his has more RAM and CPU power, but that shouldn't make the deal since we both use netbeans with the same startup options.
By now, I even tried out the RC of the 2.9 scala compiler, it didn't help much. Also, I checked if I have the correct scala plugin installed, since there might be problems when using the 2.8 plugin with the 2.9 compiler and vice versa. However, I'm using the 2.9 plugin and 2.9 compiler, so that's fine.
The problem of giving the Scala compiler more stack space is similar to specifying more heap space. Both of these options must be specified as custom JVM arguments when running the Scala compiler. However Netbeans lacks any sort of documentation on how to do it, so here it is.
The way to specify custom JVM arguments for the Scala compiler with Netbeans is by customizing build.xml for each project.
Open nbproject/build-impl.xml in the project's folder.
Search for "scalac" and you will find the following target: -init-macrodef-scalac.
Copy the whole target definition, paste it into your build.xml, and save it.
Close nbproject/build-impl.xml, from now on you will work with build.xml.
In the target you just copied, locate the <scalac> tag, the nesting will be as follows: target.macrodef.sequential.scalac
Add a custom "jvmargs" attribute to the scalac tag, it will look as follows: <scalac jvmargs="-Xss2048k -Xmx2000m" ... >
Save the build.xml. Now whenever you compile your project with netbeans, the compiler will be run with the custom jvm arguments.