I would like rubymine to be able to autocomplete for instance methods.
def get_db
return Mysql::new(DB_HOST, "x", "x", "x")
end
DB = get_db
if i where to type in
DB.
I should get all the methods of the Mysql Object.
Do i need to do something so that RubyMine can correctly do this?
No IDE can deduce what get_db will return (for a dynamic language)
Related
I am writing a test case where I am trying to mock a Resultset. To do that I already have my mocks in place
val mockedResultSet = mock[ResultSet]
val mockedRow = mock[Row]
Now when I invoke certain functions on this mocked object like .one() or .all() or .isExhausted on my ResultSet, I am able to get the desired output. For ex
doReturn(mockedRow).when(mockedResultSet).one()
or
doReturn(true).when(mockedResultSet).isExhausted
But, there are some methods in which I am directly applying a map function on the resultSet instead of applying .all() on it. For ex:-
val results = executeDBStatement(dBConnection, queryBuilderStmt)
if (!results.isExhausted) {
val res = results.map(row => {
// iterate over the result and create a list of case classes
}
)
}
Here I am not able to mock the map function behavior of ResultSet. Please let me know how I can mock the resultSet in such situations. Thanks in advance !!!
It's usually not advisable to mock objects that you don't own (check this article for more detail)
So ideally in your scenario you would have a repository class for which you'd write integration test against an in-memory database (I'm assuming you are using SQL with JDBC as you don't specify) so you have your DB interactions encapsulated there and properly tested and then you can go and mock said repository when you have to test any other class in your system that depends on in.
Now, if for some reason you still wanna mock the ResultSet, it would be nice to know what library are you using and what exact error are you getting while trying to stub the map function.
Assuming that I have a Scala case class that is persisted using the Salat/Casbah/Mongo stack, I want to set up pre-persistence validation logic like I could easily do in Rails using ActiveRecord hooks or in Java using JSR 303 bean validation.
Perhaps there is a better way to think about this in a functional paradigm, but I want to accomplish something like the following:
case class SomeItem(
id: ObjectId = new ObjectId,
someProperty: String) {
#PrePersistence
def validate() = {
//perform some logic
//fail document save in certain conditions
}
}
I am having trouble finding any documentation on how to do something like this in Salat. I do see a #Persist annotation but it seems focused on serializing specific values and not creating hooks.
It seems like one option is to override the save method in the SalatDAO for my case class. Does anyone have an example of this or know of a better, built-in way to handle validation tied to a pre-persistence event?
Thanks!
Salat developer here.
Yes, #Persist is simply for ensuring that fields that aren't in the constructor are serialized - this is particularly useful for manipulating data in MongoDB. One example is where you want to ensure that all the fields are populated with a value so you can sort sensibly, but the value is an Option which may not be present.
Unfortunately, the Java driver doesn't offer lifecycle callbacks like the Ruby driver :(
But what you want should be easy enough to do. Please file an issue at https://github.com/novus/salat/issues and describe how you would like the validation to behave - we can start a discussion and I can try to get something in for you in the 1.9.2 release.
When using the Grails MongoDB GORM Plugin (v 1.0.0.GA) standalone (i.e. WITHOUT the Hibernate jars), are the listener events supposed to work?
I've got domain classes with afterInsert, afterUpdate, etc but the event either doesn't fire or the methods are just not getting called.
I'm not seeing any specific guidance on this in the plugin docs. Does anyone know what's supposed to happen? Thanks.
Answering my own question for the benefit of others who may find it:
Apparently, when using MongoDB/GORM without Hibernate, GORM finds the event listeners by looking for the method signature on your domain object class. A closure won't do work (despite the fact that it will work when using Hibernate).
Thus, you cannot use a pattern like this:
class A {
int blah
String foo
def afterInsert = { ... }
}
Instead, do this:
class A {
int blah
String foo
def afterInsert() { ... }
}
I know it's not directly possible to serialize a function/anonymous class to the database but what are the alternatives? Do you know any useful approach to this?
To present my situation: I want to award a user "badges" based on his scores. So I have different types of badges that can be easily defined by extending this class:
class BadgeType(id:Long, name:String, detector:Function1[List[UserScore],Boolean])
The detector member is a function that walks the list of scores and return true if the User qualifies for a badge of this type.
The problem is that each time I want to add/edit/modify a badge type I need to edit the source code, recompile the whole thing and re-deploy the server. It would be much more useful if I could persist all BadgeType instances to a database. But how to do that?
The only thing that comes to mind is to have the body of the function as a script (ex: Groovy) that is evaluated at runtime.
Another approach (that does not involve a database) might be to have each badge type into a jar that I can somehow hot-deploy at runtime, which I guess is how a plugin-system might work.
What do you think?
My very brief advice is that if you want this to be truly data-driven, you need to implement a rules DSL and an interpreter. The rules are what get saved to the database, and the interpreter takes a rule instance and evaluates it against some context.
But that's overkill most of the time. You're better off having a little snippet of actual Scala code that implements the rule for each badge, give them unique IDs, then store the IDs in the database.
e.g.:
trait BadgeEval extends Function1[User,Boolean] {
def badgeId: Int
}
object Badge1234 extends BadgeEval {
def badgeId = 1234
def apply(user: User) = {
user.isSufficientlyAwesome // && ...
}
}
You can either have a big whitelist of BadgeEval instances:
val weDontNeedNoStinkingBadges = Map(
1234 -> Badge1234,
5678 -> Badge5678,
// ...
}
def evaluator(id: Int): Option[BadgeEval] = weDontNeedNoStinkingBadges.get(id)
def doesUserGetBadge(user: User, id: Int) = evaluator(id).map(_(user)).getOrElse(false)
... or if you want to keep them decoupled, use reflection:
def badgeEvalClass(id: Int) = Class.forName("com.example.badge.Badge" + id + "$").asInstanceOf[Class[BadgeEval]]
... and if you're interested in runtime pluggability, try the service provider pattern.
You can try and use Scala Continuations - they can give you the ability to serialize the computation and run it at later time or even on another machine.
Some links:
Continuations
What are Scala continuations and why use them?
Swarm - Concurrency with Scala Continuations
Serialization relates to data rather than methods. You cannot serialize functionality because it is a class file which is designed to serialize that and object serialization serializes the fields of an object.
So like Alex says, you need a rule engine.
Try this one if you want something fairly simple, which is string based, so you can serialize the rules as strings in a database or file:
http://blog.maxant.co.uk/pebble/2011/11/12/1321129560000.html
Using a DSL has the same problems unless you interpret or compile the code at runtime.
I'd like to generate method-chaining setters (setters that return the object being set), like so:
public MyObject setField (Object value) {
this.field = value;
return this;
}
This makes it easier to do one-liner instantiations, which I find easier to read:
myMethod (new MyObject ().setField (someValue).setOtherField (someOtherValue));
Can Eclipse's templates be modified to do this? I've changed the content to include return this; but the signature is not changed.
I confirm eclipse (up to 3.5RC1) does not support "method chaining" setter generation.
It only allows for comment and body customization, not API modification of a setter (meaning a generated setter still return 'void').
May be the plugin Builder Pattern can help here... (not tested though)
Classic way (not "goof" since it will always generate a "void" as return type for setter):
(source: eclipse.org)
Vs. new way (Builder Pattern, potentially used as an Eclipse plugin)
alt text http://www.javadesign.info/media/blogs/JDesign/DesignConcepts/DesignPatterns/GOF/Creational-BuilderPatternStructure.jpeg
Don't use eclipse myself, but you'll have to change one of the standard templates if you can't find a feature.
It's called method chaining by the way (which might help with a Google search or two).