ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: integrating lucene with ibatis - advice wanted
Date Tue, 16 Mar 2010 15:32:48 GMT
Hi Andrius,
very nice to meet you and congratulations for the idea, I fount it
brilliant. These are just my 2 cents.
generally speaking, I'd suggest you to implement the solution number
1: 1 interceptor and 1 annotation, nothing more, clear and reusable
solution;
2 is also great and easy to implement, but IMHO 1 is less difficult to
understand also by people involved in your project;
I don't agree 3 would be the best way, 1 and 2 are more reusable,
moreover involves more dependencies!

A small question: do you intend to Open Source it? I'd be very very
interested on having a look on it and it would be an excellent iBatis
3rd part extension.

Thanks a lot for sharing your thoughts.
Simo

http://people.apache.org/~simonetripodi/



On Tue, Mar 16, 2010 at 1:35 PM, Andrius Juozapaitis <andriusj@gmail.com> wrote:
> Hey guys,
> I created a framework I plan to use for a few projects in-house, using
> ibatis 3. I enjoy the separation of sql, mapping and domain objects, but I
> have a pretty complex domain model (first class objects may have any number
> of attributes, hierarchical if neccessary), so writing sql and taking care
> of things like sorting and paging gets really hard, and screws up the
> performance. I tried using apache lucene to take the actual searches off my
> hands, and it works like a charm. I annotate  the domain objects with
> @Indexable annotations, and pass the mapper name (which is retrieved from
> the spring context), that can query the objects from the db, and index the
> properties and attributes of the first class objects accordingly *on the
> application startup*. This builds an index in memory, and the lucene queries
> just return the IDs of the matching documents, sorted and filtered, and with
> convenient things like totalCount for paging implementation. The actual data
> can then be retrieved by simply querying by the primary keys from the
> relevant tables.
> Now, there is the issue of how to synchronize the database state with the
> lucene index. I see a few ways to implement this:
> 1. Mark the mapper methods that are supposed to change the state of the
> database with a marker annotation, and create an aspect that intercepts
> those calls, and updates the lucene index.
> This has a nasty side effect, that if someone changes the data in the db
> directly, index won't know about it until the application is restarted, but
> technically, I can live with that.
> 2. Create an aspect, that intercepts certain calls in the Ibatis layer, and
> depending on the operation at hand (insert, update, delete), updates the
> lucene index. Beats annotating the methods, and is semi-automatic. Not sure
> at which layer I should intercept this, though - hence, if there's a
> definite place to hang this aspect on, I'm all ears.
> 3. Create database triggers, that would fire the events on
> insert/update/delete using JMS or any other communication mechanism. This is
> probably the best way to go (my objects have well defined identities), but
> requires a lot of coding, and would kill the performance on update-heavy
> operations (imports and such), as the network roundtrip will be required
> from app server->db  server->[app server->db server]->app server (square
> brackets representing the call of the lucene index update by the trigger),
> not to mention the hurdles of setting up JMS producer in postgres
> environment...
> There are probably other ways to implement this - I would be very grateful
> if you guys could share your insights on this.
> Thanks in advance,
> Andrius

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org


Mime
View raw message