Using Neo4j Graph Databases With ColdFusion

After last week, I decided to put off picking a new frontend platform for my Semantic Web rubric project and focus a bit on the server backend.

Since this is just a proof-of-concept project at this point I can afford to take some risks in choosing technologies. I’ve been following the developments around using graph databases for storing data, especially for Semantic Web applications. One project that kept coming up was Neo4j, a graph database engine built in Java. I figured now was a good time to try it out. My server-side logic is built in ColdFusion, and integrating open source Java projects like Neo4j into CF applications is generally a snap.

Aside from one hiccup, porting Neo4j’s 1-minute Java “Hello World” example to CFML proved to be fairly straightforward. The process I used to get this working is detailed below. I’d suggest that you skim over the Java example before continuing – I’m sure I left out some of the exposition.

First add the Neo4j Jar files to the ColdFusion server:

  • Download the Neo4j “Apoc” distribution and unpack it somewhere convenient. I’m using Mac OS X, so I put things like this in ~/lib/neo4j-apoc-1.0
  • Add the Neo4j JAR files to the ColdFusion classpath. Log into your ColdFusion Administrator, and select Server Settings -> Java and JVM. Enter the path to the lib folder in your Neo4j distribution in ColdFusion Class Path
  • Restart your ColdFusion server. If you’re at all nervous, log back in to the ColdFusion Administrator and verify that the Neo4j jars are indeed listed on your classpath.

Once this is complete, you can initialize a new database for your ColdFusion app. Decide where you want the CF server to create the Neo4j data files and pass that to the object’s init() method. I put mine in a folder under /tmp on Mac OS X.

<cfset dbroot = "/tmp/neo4jtest/" />

<cfset graphDb = createObject('java',
                  "org.neo4j.kernel.EmbeddedGraphDatabase") />
<cfset graphDb.init(dbroot & "var/graphdb") />

[Aside for non-ColdFusion folks: CF doesn't instantiate Java objects quite how you'd expect. The call to CreateObject() just gets a handle on the class itself. Calling init() on the resulting handle actually instantiates the class via the appropriate constructor.]

Just as in the Java example, it’s good to surround your connection with a try/catch block that will close your database connection if you throw an error. As I was working with Neo4j I would periodically lock up my database and not be able to connect without restarting CF. Adding a CFTRY/CFCATCH block cleared this right up.

<cftry>
   <cfset tx = graphDb.beginTx() />

   <cfscript>
     tx.success();
     WriteOutput("Success.");
   </cfscript>

   <cfset tx.finish() />

  <cfcatch type="any">
     <cfset graphDb.shutdown() />
     <cfdump var="#cfcatch#">
   </cfcatch>
</cftry>

<cfset graphDb.shutdown() />

Where things got really sticky was the use of Java enumerations to declare the available relationship types for the graph:

 /* Java code */
 public enum  MyRelationshipTypes implements RelationshipType
 {
    KNOWS
 }

To my knowledge there’s no way to declare something like this in standard CFML. I likely could have wrapped this in a Java class of some sort and loaded it through CreateObject(), but that wouldn’t have been true to the spirit of ColdFusion. So I dug around in the Neo4j docs and found an answer: relationships can be created dynamically at runtime from a static method on the class org.neo4j.graphdb.DynamicRelationshipType. I created an instance of DynamicRelationshipType for the “KNOWS” relationship and loaded it into a Struct, anticipating caching them in Application scope for a real application.

 relationship = CreateObject("java",
                             "org.neo4j.graphdb.DynamicRelationshipType");
 MyRelationshipTypes = structNew();
 MyRelationshipTypes.KNOWS = relationship.withName( "KNOWS" );

It might be interesting to see if these relationship enumerations could be generated and compiled by something like JavaLoader. I’m not yet aware of any downsides with dynamic relationships besides the obvious lack of compile-time checking.

The rest of the exercise follows without any real suprises:

 firstNode = graphDb.createNode();
 secondNode = graphDb.createNode();
 relationship = firstNode.createRelationshipTo( secondNode,
                                         MyRelationshipTypes.KNOWS );

 firstNode.setProperty( "message", "Hello, " );
 secondNode.setProperty( "message", "world!" );
 relationship.setProperty( "message", "brave Neo4j " );

 WriteOutput( firstNode.getProperty( "message" ) );
 WriteOutput( relationship.getProperty( "message" ) );
 WriteOutput( secondNode.getProperty( "message" ) );

And there you have it! A quick and dirty Neo4j application built with CFML.

I’ve put a little work into developing a Neo4j helper class that hides some of these warts in a nice clean CFC. As soon as I can get eGit to behave I’ll post the files on GitHub.

Losing my religion

So I ordered an iPad because I want to build things for it. My first project was going to be a port of the Rubricator concept — the larger screen and interest of the education community made this seem like a good fit for an iPad application.

Unfortunately, I made a crazy choice in February and started down the path of the Flash CS5 Packager for iPhone rather than commit to the straight-up Apple toolchain I’d been dabbling with for the last year and a half. Why Flash? I was hoping I’d be able to use at least some of my Flex expertise – full-blown Flex components weren’t supported, but ActionScript techniques translate readily back to plain old Flash. This would also give me a chance to experiment with a lightweight AS-only component set (minimalcomps) and an interesting Dependency Injection framework I’d been hearing a lot about (Robotlegs).

Not only was this process awkward, my first crack at the app itself was painfully slow. It was obvious that the techniques I’d developed for Web and desktop application development were not going to be enough to make a reasonable iPhone app, even with a good UI concept. I was beginning to see the dark at the end of the tunnel for this pet project of mine.

But then disaster – Apple pulled the rug out from under the entire Packager for iPhone concept, taking their ball and going home. Boy howdy, I loved middle school. It took a few weeks, but yesterday Adobe finally cried uncle and the proprietary software apologist in me died a little. The two companies that saw me through Microsoft’s bungled hegemony over the Web are now taking shots at each other. Can’t mommy and daddy just get along?

So where do I go now? Do I succumb to Apple’s strong arm tactics and commit to the platform in the way they so desperately want? Do I ditch Apple and run careening for Google and Android?  Or do I run to something like PhoneGap, which promises a more open way to develop apps with JavaScript and Web standards.

Anybody wanna buy an iPad, slightly smudged?

Synchronized Web development workflow

It’s been six years since I switched from HomeSite to Eclipse+CFEclipse as my primary ColdFusion development environment. At the time, my switch was primarily driven by my switch to Mac for development, but the desire for integrated support for version control (e.g. Subversion) directly within in the IDE helped with that as well.

One of the things that has long bugged me about developing ColdFusion apps locally on a dev box (i.e. not on a shared network server) is the need to place project files directly in a Web root somewhere – for example, C:\InetPub\wwwroot on Windows/IIS or in C:\ColdFusion9\wwwroot if you use ColdFusion’s built-in Web server. This throws off my game in two ways:

  1. Browsing to where your files live (in Finder/Explorer, or via the command line) inevitably adds an extra step to every task
  2. Placing the project home outside your user space on the OS makes it more likely you’ll lose the files when upgrading/uninstalling/migrating.

Pain point one could be tackled by sprinkling my system with aliases, shortcuts and/or symbolic links. This reeks of configuration, and would be something I’d need to duplicate on any system I use.

Pain point two there is really the kicker. Sure, using version control keeps you from losing your work, but rebuilding the workspace after a system migration can take a long time. I rarely migrate applications when I get a new system; I prefer to just move the user files and reinstall the apps manually. This periodically cleanses the system and keeps me up to date on patches, even on apps I don’t use often.

I tried keeping my actual project files in a workspace somewhere convenient, such as in my home directory or in the root of the drive (e.g. C:\workspace\MyColdFusionApp)  and then copy the files to the server root to test them. I tried both manual copying and even Subversion commands, but I couldn’t keep that up for long. Part of the benefit of developing anything locally on your system is removing the step of uploading your code to a server to test it, and I was basically backsliding towards that kind of process.

But the idea was sound, and I looked around for something that would painlessly synchronize two folders in different parts of the drive – the project files in my workspace, and the files in a folder under the Web root. My last resort would be to use something like rsync, but I looked around for some sort of plugin for Eclipse – something that could keep the preferences as part of the Eclipse project and/or workspace and be easy to migrate and hard to lose.

With a little digging I found FileSync – a plugin which really fit the bill. It’s open source, and if you can look past the, ah, unpolished Web site of its creator the plugin works pretty well. When I save a file in my workspace, it painlessly gets pushed out to the Web server root for testing.

The plugin also appears to work with network drive targets, so you may be able to use it to publish changes out to a preview or QA server automatically, but you should probably be using some sort of version control for that. :)

April 14, 2010Permalink

Hey iPad – Twitter called and it wants its haters back

I’ve spent the last few days playing with my new iPad. I don’t really think of myself as an Apple fanboy, but evidence might be starting to mount. I originally wanted an iPad for application testing – I’m working on a few projects that would benefit from ultra-mobility and reasonable screen size.

To me this is a whole new category of device, and I wanted to get a real feel for what this thing was all about. I already have or use the devices around the niche the iPad appears to be destined for – the MacBook, the iPhone, netbook – but I really did see this as Something Completely Different. I desperately wanted to like the Windows Tablet; I’d been an early Palm user (III/V/m105) and I tried two early generations (a Compaq TC1000 and a Toshiba M205). I  carried them from meeting to class to meeting, but it never clicked. I saw the potential, but the experience was truly lacking for me.

Yes, I am still ticked off that there’s no Flash – I enjoy building apps in Flex and AIR. I’m even more disappointed that Apple appears to have removed the blue brick icon when a missing plugin is needed for page content. I have yet to see one in Safari when browsing Web sites. This was serving as an ensign for the Flash community.  If Apple has indeed removed this emblem, perhaps Flash developers should put that icon in the alternate content area of the embed/object tag. [Update 4/13/10: Someone has done precisely that]

But the real amazing thing to me has been all the vitriol about the iPad – it’s like the usual unsocialized nonsense of Slashdot has exploded all over the Web. It frankly reminds me of the early days of Twitter – “Why would anyone want to know what I had for breakfast?” was the usual slant. And that showed that they didn’t *get it*

I also feel the same sort of guarded optimism as I did with Twitter – something’s different here. Now that folks with an inclination to develop have the actual devices, There Will Be Code. And from that code will come new kinds of applications and uses that we have only begun to consider.