Re: [ppa-dev] GSoC: FTS support in phpPgAdmin

[Ivan Z. <iva...@gm...>]

Hello,

Please have a look at the patch attached. Actually, it is not a patch,
just an opportunity to ask several questions. It's really small; it
adds FTS tab on the database level with listing of existing
configurations inside and several fake links there.

Meantime, the questions are:

1. What is the best place for SQL queries like the only one in
fulltext.php? I saw approach like cycles on $data->getSmth(), is it
better here?
2. Am I supposed to create classes/database/Postgres83.php? I would
place function hasFTS(){return true;} there.

I would appreciate any comments that help me to begin more serious
coding preserving all the existing practices here in the
dev-community.

--
Regards,
 Ivan


On 5/28/07, Ivan Zolotukhin <iva...@gm...> wrote:
> On 5/27/07, Robert Treat <xz...@us...> wrote:
> > On Saturday 26 May 2007 14:32, Ivan Zolotukhin wrote:
> > > 3. Few things on actual functionality, its first part to be precise. I
> > > suppose there should be following simple layout. First, we add new
> > > 'FTS' tab (conditional on 8.3 version + check if there's FTS
> > > functionality inside database, since now in 8.3 one have to apply not
> > > yet commited patch to use FTS) on the database level, say after
> > > 'Privileges' tab. After clicking on it, we should show FTS
> > > configurations available, with usual Alter/Drop buttons and comments
> > > next to them. At the bottom we should provide links to 'Create
> > > configuration', 'Create dictionary' and possibly 'Create fulltext
> > > mapping' (it may be reasonable to put this last link inside 'Inspect
> > > FTS configuration' page). Would be very glad to hear your thoughts on
> > > that.
> > >
> >
> > That sounds pretty close to how I envisioned it.  With this method, most of
> > the changes for the gui would live in it's own file, like fulltext.php or
> > something.  General functions would be added under classes/ were appropriate.
> > A simple patch to get started would include adding the menu item with perhaps
> > just a "fts settings" part so people could see existing configurations. It
> > might be feasible to make this information backward compatible (search
> > through each schema for a pg_ts_config table for example) but not mandatory.
> > You can then do successive patches that add each piece of functionality as
> > you go, though I don't suspect it should be too crazy.
>
> Yep, agree with above. The only question is about changes that needed
> in common stuff, like addon of FTS operator @@ in $selectOps in
> classes/database/Postgres71.php. I would prefer to make things like
> that inside condition if FTS actually installed, but that means I
> should separate them from main place to specify such lists, adding new
> values to arrays in files included later. It is not good since it
> spreads important settings over the code. What would be the best
> practice for this?
>
> --
> Regards,
>  Ivan
>