On Fri, 11 Mar 2005 11:18:48 +0100, Martijn Tonies <m.tonies@...> wrote:

>
> Well, connecting to the database from an external function
> is generally a no-go area.

Well, this must be a misunderstanding.
The external function will connect to the fts-server, which in turn might have a
connection open to the FB server to wait for events.
The UDFs will in no way connect to the the FB server themselves.

> External functions should be fast. Connecting to a database
> network latecy because of your server-side app being on
> another machine doesn't fit this description.

Uhm, so external functions doing heavy computing aren't allowed, too?
I don't see the point here, really.

> Mind you: executing an external function will block the server
> thread executing it!

Okay, this might be a crucial point.
I don't know about FB's internal threading policies, so I guess it's good
that I discuss my idea here, after all. :)

Well, look at the sample stored select-procedure. Whether it selects from
a table or from an external entity via a UDF (of course, I'll have to make sure
that the UDFs will never block forever for some reasons) shouldn't make a
difference to the FB server, would it?
For incremental updating, there'll be a stack for actions in the shared object
anyways, so a call for fts_update(table, id) will only append the update action
for this table to the stack, which will be processed "later".

But I notice a problem here... because I think the update will be done by
telling the fts-server a primary key and what happened to it, it has to
connect back to the server to get the actual texts it needs.
I guess I need a two-way connection, after all.
But only for updates, and those are done asynchronously. For searches, the
fts-server doesn't need info from the database.

Daniel Albuschat

--
eat(this); // delicious suicide