Agylen

This is for any Atlassian Confluence developers or contributors reading my blog. I am trying to develop a simple plugin and wanted to use the Confluence Search (v2) API but couln’t find much in the way of documentation or examples.

So I posted a question to the Confluence Forum but got no reply in three days :(. Should anyone be able to help me, the forum thread is here but I am also reposting here the text of the question:

I’m looking for examples and guidance in using the Search (v2) API in Confluence, specifically from a plugin.

I got hold of a SearchManager via Dependency Injection and obtained some results with code like the following

SearchQuery query = ...;
Search search = new Search(query, null, null);
SearchResults results = this.searchManager.search(search);

My problem is that I have no idea about which implementation of the SearchQuery interface to use and in particular how to specify a phrase to search for, since no subclass seems to provide for a way to set a query term.

Thanks in advance.

First Sun acquires MySQL, and now this:

Oracle to Acquire BEA Systems: “REDWOOD SHORES, Calif., Jan. 16 /PRNewswire-FirstCall/ — Oracle Corporation (Nasdaq: ORCL) and BEA Systems (Nasdaq: BEAS) announced today they have entered into a definitive agreement under which Oracle will acquire all outstanding shares of BEA for $19.375 per share in cash. The offer is valued at approximately $8.5 billion, or $7.2 billion net of BEA’s cash on hand of $1.3 billion. ‘We expect this deal to be accretive to Oracle’s earnings by at least 1-2 cents on a non-GAAP basis in its first full year after closing,’ said Oracle President and Chief Financial Officer Safra Catz.”

The XML 2007 Conference is over and here are my observations.

For me personally, it was a mixed bag. My talk was not very well attended and I can understand why now: I thought this was much more of a developers’ conference, but there seem to be many more MIS types and business users than developers. The median age is also much higher than the one that is characteristic of venues like OSCON or ApacheCon: silver hair abound. So it is understandable that many eyes glazed over when I started showing blobs of Java code in the second half of my talk.

One could hope of getting a lot of business leads from such a business-oriented audience, but it’s not that easy to try to sell a European consultancy to a public that is 99% US-based: very few Europeans are here.

Still, I got some nice feedback from the few developers that were attending, so I can be confident that my presentation was of good quality: it’s just that most of the audience was not the right audience.

From the attendee point of view, it was a mixed bag too. There are so many talks that are so loaded with marketspeak that they made me want to run out and do some Christmas shopping instead: shops will take your money as well, but will give you some definite value in exchange for it ;).

As is usual in such situations, you get the best value for money out of meeting other people you have only known virtually until then. One of them is Gregg Pollack (he is the guy playing Ruby on Rails in the “Get a Mac” spoof ads for Rails; if you haven’t seen them yet, do it now, they’re even funnier than the originals).

I also had a god chat with Norman Walsh about his XProc implementation project. I inquired whether he was planning to open it up to external contributions: He eventually will, but will probably rewrite it once again from scratch one more time. So I am going forward with my own implementation, which is currently a labour-of-love, side project to which I am obviously not dedicating any significant amount of time at the moment. We agreed to talk again in a couple of months from now and see how far we’ve come.

The highlight of the trip for me, however, was meeting Sally and Yoav. Curiously, even though both are Bostonians and they worked together in the Apache PRC, they had never met face-to-face before. It took me coming to Boston to catalyze their meeting. We had a very nice dinner in Boston’s North End and a good deal of talk about Apache and our respective jobs and lives.

Cost of a trip to Boston for the XML Conference: about $2000 with MasterCard.

Making new friends there: priceless.

I think this comment that Danny Ayers left on my In defence of the RDBMS post deserves to be discussed in a post of its own:

The point about relational databases as an integration technology is well made, but I’m curious to know why you consider RDF worse as a storage medium. It has definite advantages over OO/RDBs when it comes to integration on the web (thanks to the use of URIs as keys, and the open world model).

For persistence I can’t see any way it’s worse than OO/RDBs (in fact quite a few RDF stores use RDBs for persistence under the hood). What’s more, RDF has well-defined serializations (such as RDF/XML) which means that not only is the data portable between stores, it can also be dumped in a *standard* form. (For persistence it’s perfectly reasonable to divide the data up into manageable chunks and distribute them across RDF/XML files).

If “data lives much longer than applications”, then isn’t it better to take advantage of a clear standard, rather than the quasi-standards found in SQL implementations, or for that matter the more proprietary models found in OO DBs..?

Well… yes and no.

Let me first point out the fact that I wrote about “using RDF as a persistent storage medium just because it’s more flexible than a RDBMS”. That’s what I was objecting to (and before you ask: no, it’s not a hypothetical scenario) and not the usage of RDF per se. As Gavin King wrote in the post I was responding to: “Database refactoring is possible and practical.” and you shouldn’t be using some new, unproven technology just because refactoring and maintaining SQL databases is hard.

Second, RDF data might be portable when it is serialized as XML or N3, but once it is persistently stored, it is usually in a proprietary format that can only be accessed with a proprietary API. If I have, say, a Jena model stored in an RDBMS, all I have is a essentially a single table with three columns (subject, predicate and object) where all values have been mangled so much that the number 42 becomes Lv:0:42:http://www.w3.org/2001/XMLSchema#nonNegativeInteger4 and so on.

Contrast that to an SQL database schema where, if the designer didn’t purposefully obfuscate it, it’s usually possible to reverse engineer it, sometimes just by looking at the names of tables and columns, and at foreign keys to infer relationships. There are also mature tools to move data between different databases.

You could argue that I am comparing things that are at different levels, that I should be looking at N3 serialization format as an equivalent of SQL, and that complaining about the non-portability of Jena models is equivalent to complaining about not being able to move MySQL data files to Oracle. If you did that… well, I’d concede you have a point

But the fact remains that, as long as I have my data served by a reasonably well-known RDBMS and I am using a reasonably well-designed schema, I’ll be able to find a (oftentimes cheap or free) tool that allows me to make sense of that data, analyze it, transform it, plot it, report it, you name it.

Without even much thinking about it, I can fire up mysql, psql or sqlplus from the comman line and type:

select avg(salary) as a from person
  group by age having avg(salary) > 50000
  order by a desc;

I’m not really up to speed with SPARQL, but I don’t think it’s able to do that just yet. Not to mention how efficient it would be, whereas RDBMS have been optimized for 30 years in order to be blazingly fast at doing joins, sorts, groupings, projections, and the like. You know, the kind of things business people tend to ask from a data store.

So, to sum it up, RDF does really shine “when it comes to integration on the web”, especially when we are doing integration between really heterogeneous systems, without much in the way of predefined agreements between them. But I wouldn’t right now, given the maturity of tools, design a system that had an RDF storage system at its core, unless I had some compelling, specific reason for doing so.