Subject | Re: [IBO] Full Text Search implementation |
---|---|
Author | Jason Wharton |
Post date | 2010-09-19T18:43:15Z |
Robert,
I said:
doing the work necessary to allow for that. I did not surface an external
IB_Transaction property that allows you to integrate in with an
existing/external transaction context. Instead, the TIB_FTS_Sync component
creates and maintains its own internal transaction to work with. This means
that this component is only capable of acting upon changes that have become
committed.
planned.
providing an external IB_Transaction that you can plug it into.
Do you need this capability?
Thanks and sorry for the confusion.
Regards,
Jason Wharton
I said:
> The full text index synchronization component can be put inside of yourI mis-spoke. I meant to design it to work this way but I stopped short of
> transaction context and told to function in conjunction with updates as
> they
> are happening rather than waiting until they are committed. You would just
> call the ResyncQueue method (I think that's what I called it) after each
> time the index is impacted.
doing the work necessary to allow for that. I did not surface an external
IB_Transaction property that allows you to integrate in with an
existing/external transaction context. Instead, the TIB_FTS_Sync component
creates and maintains its own internal transaction to work with. This means
that this component is only capable of acting upon changes that have become
committed.
> The reason you normally have to wait until your changes are committed isThis is actually true in all cases because I didn't go as far as I had
> because typically the synchronization is being run in a seperate service
> application in a single separate place. You won't see any changes until
> they
> are committed.
planned.
> If you cause it to do the sync "on-demand" in your application directlyThis could be true if you want me to go ahead and follow through with
> within the same transaction scope, then everything will still be just fine
> whether things are committed or rolled back. The only difference is you
> will
> be rolling back changes to the indexes rather than to the queue tables.
providing an external IB_Transaction that you can plug it into.
Do you need this capability?
Thanks and sorry for the confusion.
Regards,
Jason Wharton
> Let me know if you need more assistance.
>
> I'm starting to feel better and so by Monday I should be back in full
> motion.
>
> Regards,
> Jason Wharton
>
>
> ----- Original Message -----
> From: "robert.gilland" <robert.gilland@...>
> To: <IBObjects@yahoogroups.com>
> Sent: Wednesday, September 01, 2010 10:36 PM
> Subject: [IBO] Full Text Search implementation
>
>
>> In May 2009 I implemented Full Text Search into my application.
>>
>> My application only used ibobjects for instantiating the Full Text Search
>> metadata and initial population of this data. It was my assumption that
>> the metadata would do all the work for ensuring the full text searches
>> were up to date.
>>
>> For example:
>>
>> Application calls INSERT INTO MYDATATABLE;
>>
>> I expected then the triggers implemented with Full Text Search would then
>> take care of the rest.
>>
>> HOWEVER.
>>
>> I was wrong it seems.
>>
>> It seems that the below is the truth:
>>
>> I call
>>
>> INSERT INTO MYDATATABLE;
>>
>> triggers then do a POST_EVENT function which assumes that there is an
>> IBOBJECTS connection listening to the database and then the IBOBJECTS
>> syncs using the application components.
>>
>> This was not my understanding and undermines everything I did.
>>
>> Why couldn't the triggers have done everything?
>>
>> Is there something I can call that can in a fast way process all Full
>> Text
>> Search Queued instructions?
>>
>> So I can call it just before I call the Full Text Search function every
>> time?
>>
>> Kind Regards,
>>
>> Robert.
>>
>>
>>
>>
>>
>>
>> ------------------------------------
>>
>> ___________________________________________________________________________
>> IB Objects - direct, complete, custom connectivity to Firebird or
>> InterBase
>> without the need for BDE, ODBC or any other layer.
>> ___________________________________________________________________________
>> http://www.ibobjects.com - your IBO community resource for Tech Info
>> papers,
>> keyword-searchable FAQ, community code contributions and more !
>> Yahoo! Groups Links
>>
>>
>>
>
>
>
> ------------------------------------
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
> InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
> papers,
> keyword-searchable FAQ, community code contributions and more !
> Yahoo! Groups Links
>
>
>