I actually did look at it - but I didn't like the API, and it seemed a bit heavyweight for me. Simple lucene is enough for my needs, so I didn't add that much of effort to get it running. Their forums aren't that active on this topic either. Might take a second look though - thanks!
regards, Andrius On Tue, Mar 16, 2010 at 7:33 PM, Ashok Madhavan <ashok.madha...@gmail.com>wrote: > 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 > >
