Tag | terracotta
Formatting Date in Lucene Queries
Little did I know that my adventures with Terracotta would soon require me to dip my toes into Lucene so, you know, we could actually find the objects in Terracotta.
So I had an odd problem where Lucene was only searching by the year. For example, I had an object with the date of 20090915. And so I made my date range as:
datevalue:[19000101 TO 20091231]
And that worked fine. Then I changed the query to:
datevalue:[20090101 TO 20091231]
And it didn’t find it! Why not?
Even though it’s not spelled out in the documentation, you have to use the ISO Format for date/time objects. So I changed the query to:
datevalue:[2009-01-01 TO 2009-12-31]
And it started working
Using Jython as a Terracotta Command Line
My new position at work was best described to me from my AVP: “Figure out how to make it work.” The first thing that I need to see if it will work is Terracotta. Terracotta is cool stuff — more to follow on it later. Probably.
If you know me well enough, or have been reading this blog for a while, you know that I’m a big fan of Python. Well, if I need to figure out how to “make it work” it generally involves Jython. That way, I can open a prompt up and noodle around at the object and see what makes them tick. To me, this could be especially important in Terracotta since you have objects floating around everywhere.
Getting Jython as a command-line interface into a Terracotta cluster is trivial — almost not worth blogging about. And the result is oh-so cool.
Here is my Jython script. It just imports some common things and a Spring application context, and then get an object from the context. That object contains my Terracotta root object, which means that it stays in sync across my client and server JVM’s.
import sys,os
from org.springframework.context.support import ClassPathXmlApplicationContext
if __name__ == '__main__':
ctx = ClassPathXmlApplicationContext("applicationContext.xml")
worker=ctx.getBean("worker")
Not that there isn’t anything specific to Terracotta in there — just like it should be.
I then wrote a shell script to setup my environment and run my Jython script in a Terracotta-instrumented environment. I actually run everything in Windows (unfortunately) so I have some Cygwin magic in there to change the classpath and to run the dso-java.bat in a cmd window:
#!/bin/sh cp="dowork.jar:/c/Projects/jython2.5.1rc2/jython.jar" cygstart bin/dso-java.bat -classpath `cygpath -mp $cp` org.python.util.jython -i $1 $2 $3 $4 $5
This allows me to run any script in a Terracotta cluster and then keep a command line open to I can muck around with stuff. Thejython.jar I use is a stand-alone install. I’ve just found that easier than worrying about where all modules are.
So now I just enter the shell script name with my Jython script as an argument and away I go!
And this works exactly as I expected. I can see the state of the root in the worker object, update that state in another clustered JVM, and then see that state immediately in my Jython prompt.
I’m sure you can do the same with Groovy, JRUby and their ilk. But I use Jython. It’s just how I roll
