Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 17790 invoked from network); 16 Mar 2010 18:12:59 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 16 Mar 2010 18:12:59 -0000 Received: (qmail 4356 invoked by uid 500); 16 Mar 2010 18:12:58 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 4340 invoked by uid 500); 16 Mar 2010 18:12:58 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 4333 invoked by uid 99); 16 Mar 2010 18:12:58 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Mar 2010 18:12:58 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of andriusj@gmail.com designates 72.14.220.154 as permitted sender) Received: from [72.14.220.154] (HELO fg-out-1718.google.com) (72.14.220.154) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 16 Mar 2010 18:12:53 +0000 Received: by fg-out-1718.google.com with SMTP id e21so916397fga.6 for ; Tue, 16 Mar 2010 11:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=dsiN292N7b2TJA74kjTlTSEyMRcwTS3ca6oONoA9UAU=; b=UFKgEDkyJVTUV0e8BoPS0CWstD/rxN5XFftlFErumOqb0GbI2wgXqIpFY1vgAEjijz Lqg7akF5OrPbfKZaIfP/G9LzW8jSVKhYnDa7WUVu7baR4hnamaWmE7J/a0baLEBn2pjX Xjef4he/vxvlEtHORks3oKWSfNPcVdxa/+/Vw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=f2x54Aij2reqKE9C6B0YMjDI3BnSMYK86RSDClOPodOKloGFllrI+netEXr6VnEC72 zdFrnW2Y6ObFyAdbfIejBBhjOrI/5IWRiUPaU/Q4jXX8iMM6PuiqPIAZTqASdsM/4Mbo MXWscm2BR3jf6lR945sKoOOowjhGHAIuZ5ego= MIME-Version: 1.0 Received: by 10.87.55.11 with SMTP id h11mr1884309fgk.56.1268763149482; Tue, 16 Mar 2010 11:12:29 -0700 (PDT) In-Reply-To: References: <4173dc211003160832k9970597j424d4f90cd749751@mail.gmail.com> Date: Tue, 16 Mar 2010 20:12:29 +0200 Message-ID: Subject: Re: integrating lucene with ibatis - advice wanted From: Andrius Juozapaitis To: user-java@ibatis.apache.org Content-Type: multipart/alternative; boundary=001485f7d664d43a4d0481eef017 --001485f7d664d43a4d0481eef017 Content-Type: text/plain; charset=ISO-8859-1 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 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 > 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.tripodi@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 < > 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 > >> > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org > For additional commands, e-mail: user-java-help@ibatis.apache.org > > --001485f7d664d43a4d0481eef017 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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.madhavan@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 <andriusj@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)-bus= iness
> 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 =A0multi-module maven project. I = could
> probably get rid of most of the persistence altogether and use hiberna= te,
> but I still want to use the same domain objects in gwt and spring laye= rs,
> and hibernate kinda ruins the idea by enhancing the domain objects, so= you
> have to fallback to maintaining parallel hierarchies of DTOs and domai= n
> 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 enou= gh
> interest for it, but I would still like to hear more oppinions about t= he
> matter, before diving into implementation.
> regards,
> Andrius
>
> On Tue, Mar 16, 2010 at 5:32 PM, Simone Tripodi <simone.tripodi@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 reusabl= e
>> solution;
>> 2 is also great and easy to implement, but IMHO 1 is less difficul= t to
>> understand also by people involved in your project;
>> I don't agree 3 would be the best way, 1 and 2 are more reusab= le,
>> 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 iBa= tis
>> 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-hou= se, using
>> > ibatis 3. I enjoy the separation of sql, mapping and domain o= bjects, but
>> > I
>> > have a pretty complex domain model (first class objects may h= ave any
>> > number
>> > of attributes, hierarchical if neccessary), so writing sql an= d taking
>> > care
>> > of things like sorting and paging gets really hard, and screw= s up the
>> > performance. I tried using apache lucene to take the actual s= earches off
>> > my
>> > hands, and it works like a charm. I annotate =A0the domain ob= jects with
>> > @Indexable annotations, and pass the mapper name (which is re= trieved
>> > from
>> > the spring context), that can query the objects from the db, = and index
>> > the
>> > properties and attributes of the first class objects accordin= gly *on the
>> > application startup*. This builds an index in memory, and the= lucene
>> > queries
>> > just return the IDs of the matching documents, sorted and fil= tered, 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 st= ate with
>> > the
>> > lucene index. I see a few ways to implement this:
>> > 1. Mark the mapper methods that are supposed to change the st= ate 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 dat= a 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 Iba= tis layer,
>> > and
>> > depending on the operation at hand (insert, update, delete), = updates the
>> > lucene index. Beats annotating the methods, and is semi-autom= atic. Not
>> > sure
>> > at which layer I should intercept this, though - hence, if th= ere'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 mec= hanism.
>> > This is
>> > probably the best way to go (my objects have well defined ide= ntities),
>> > but
>> > requires a lot of coding, and would kill the performance on u= pdate-heavy
>> > operations (imports and such), as the network roundtrip will = be required
>> > from app server->db =A0server->[app server->db serve= r]->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 post= gres
>> > 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
>>
>
>

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


--001485f7d664d43a4d0481eef017--