did you look at compass ( http://www.compass-project.org/).
as per their documentation hey already have ibatis + lucene covered. ( maybe it is ibatis 2.x ). regards ashok On Tue, Mar 16, 2010 at 9:57 AM, Andrius Juozapaitis <andri...@gmail.com> wrote: > Simone, > Thanks for the compliments, this functionality is by no means complete, and > it's currently a part of a reasonably proof-of-concept > (smartgwt-gwtrpcdatasource-gwtdispatcher (command pattern for gwt)-business > logic in spring/jms/aspects/springmvc/spring > security/etc-lucene-ibatis-postgres), but I already refactored it to a > number of smaller maven modules in a multi-module maven project. I could > probably get rid of most of the persistence altogether and use hibernate, > but I still want to use the same domain objects in gwt and spring layers, > and hibernate kinda ruins the idea by enhancing the domain objects, so you > have to fallback to maintaining parallel hierarchies of DTOs and domain > objects - you get my drift :) > I could definately release at least this part of the project as an > opensource extension, no question about that, if only there's enough > interest for it, but I would still like to hear more oppinions about the > matter, before diving into implementation. > regards, > Andrius > > On Tue, Mar 16, 2010 at 5:32 PM, Simone Tripodi <simone.trip...@gmail.com> > wrote: >> >> 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 >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org For additional commands, e-mail: user-java-h...@ibatis.apache.org
