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 <andri...@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-unsubscr...@ibatis.apache.org For additional commands, e-mail: user-java-h...@ibatis.apache.org
