From: Ivan Z. <iva...@gm...> - 2007-05-26 18:32:13
|
Hello, I'm planning details of my project now and already implemented couple of small things in PPA to study its internals. Before doing more serious work I'd like to ask experienced developers here in the list about their advices/suggestions for my work. 1. I see several similar modules in phppgadmin.cvs.sourceforge.net:/cvsroot/phppgadmin HEAD, like phpPgAdmin and phppgadmin. Seems that module I checked out (phpPgAdmin in camel style) receives PPA commit traffic. Is it really main place for development? 2. What would be more reasonable for my project: commit all changes step by step (directly in the HEAD or separate publicly accessible branch for future merge) or maintain and develop growing patch and then merge it to the HEAD with the help of key PPA developer? I would prefer commits actually, otherwise merge large set of changes would be difficult. Moreover, all my functionality is related to PostgreSQL 8.3, so most of the modifications will be conditional and won't affect users that run PPA with stable PostgreSQL versions. In any case I need a person who can help me by reviewing the code/patches at least during the first time. 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. Any comments on above and entire project are very welcomed. -- Regards, Ivan |
From: Karl O. P. <ko...@me...> - 2007-05-26 21:24:01
|
On 05/26/2007 01:32:14 PM, Ivan Zolotukhin wrote: > 2. What would be more reasonable for my project: commit all changes > step by step (directly in the HEAD or separate publicly accessible > branch for future merge) or maintain and develop growing patch and > then merge it to the HEAD with the help of key PPA developer? > In any case I need a person who can help me by reviewing the > code/patches at least during the first time. The traditional approach is to send all patches to this list for review. A trusted developer will then commit them when they're ready. Many smaller patches are better than one big patch, although presumeably each should be big enough to both work without bugs and have _some_ benefit. When everybody's had enough of this process the unoffical offical project owner, Robert Treat, or perhaps somebody else, will tell you to just go ahead and commit to HEAD yourself. (All patches are against HEAD.) There have been other approaches used by those who have relationships with developers already given permission to commit directly. Committing yourself without prior approval would be, uh, frowned upon. Karl <ko...@me...> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein |
From: Russell S. <mr...@pw...> - 2007-05-27 02:51:18
|
Ivan Zolotukhin wrote: > Hello, > > I'm planning details of my project now and already implemented couple > of small things in PPA to study its internals. Before doing more > serious work I'd like to ask experienced developers here in the list > about their advices/suggestions for my work. > > 1. I see several similar modules in > phppgadmin.cvs.sourceforge.net:/cvsroot/phppgadmin HEAD, like > phpPgAdmin and phppgadmin. Seems that module I checked out (phpPgAdmin > in camel style) receives PPA commit traffic. Is it really main place > for development? > You want the webdb module. > 2. What would be more reasonable for my project: commit all changes > step by step (directly in the HEAD or separate publicly accessible > branch for future merge) or maintain and develop growing patch and > then merge it to the HEAD with the help of key PPA developer? I would > prefer commits actually, otherwise merge large set of changes would be > difficult. Moreover, all my functionality is related to PostgreSQL > 8.3, so most of the modifications will be conditional and won't affect > users that run PPA with stable PostgreSQL versions. > Separate features as different patches. Send them to this list for review. > In any case I need a person who can help me by reviewing the > code/patches at least during the first time. > If you post them too the list, I'm sure a few of us will assist with review and comments. > 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. > > Any comments on above and entire project are very welcomed. > > -- > Regards, > Ivan > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > phpPgAdmin-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel > > |
From: Ivan Z. <iva...@gm...> - 2007-05-27 04:54:39
|
OK, thanks for the replies. I've got it and will send first patch for review here soon. On 5/27/07, Russell Smith <mr...@pw...> wrote: > Ivan Zolotukhin wrote: > > Hello, > > > > I'm planning details of my project now and already implemented couple > > of small things in PPA to study its internals. Before doing more > > serious work I'd like to ask experienced developers here in the list > > about their advices/suggestions for my work. > > > > 1. I see several similar modules in > > phppgadmin.cvs.sourceforge.net:/cvsroot/phppgadmin HEAD, like > > phpPgAdmin and phppgadmin. Seems that module I checked out (phpPgAdmin > > in camel style) receives PPA commit traffic. Is it really main place > > for development? > > > You want the webdb module. > > 2. What would be more reasonable for my project: commit all changes > > step by step (directly in the HEAD or separate publicly accessible > > branch for future merge) or maintain and develop growing patch and > > then merge it to the HEAD with the help of key PPA developer? I would > > prefer commits actually, otherwise merge large set of changes would be > > difficult. Moreover, all my functionality is related to PostgreSQL > > 8.3, so most of the modifications will be conditional and won't affect > > users that run PPA with stable PostgreSQL versions. > > > Separate features as different patches. Send them to this list for review. > > In any case I need a person who can help me by reviewing the > > code/patches at least during the first time. > > > If you post them too the list, I'm sure a few of us will assist with > review and comments. > > 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. > > > > Any comments on above and entire project are very welcomed. > > > > -- > > Regards, > > Ivan > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by DB2 Express > > Download DB2 Express C - the FREE version of DB2 express and take > > control of your XML. No limits. Just data. Click to get it now. > > http://sourceforge.net/powerbar/db2/ > > _______________________________________________ > > phpPgAdmin-devel mailing list > > php...@li... > > https://lists.sourceforge.net/lists/listinfo/phppgadmin-devel > > > > > > |
From: Robert T. <xz...@us...> - 2007-05-27 18:31:47
|
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. Really the biggest issue is seeing what happens with the tsearch patch against 8.3 core. :-) -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL |
From: Ivan Z. <iva...@gm...> - 2007-05-28 04:38:36
|
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 |
From: Ivan Z. <iva...@gm...> - 2007-06-03 23:37:31
Attachments:
ppa_fts_0.01.patch
|
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 > |
From: Guillaume `i. de R. <io...@us...> - 2007-06-04 09:22:40
|
Ivan Zolotukhin wrote: > Hello, Hello and welcome on board ;) > 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. I havn't fts installed so far. But for this patch, I can give you some comments. I will take some time to install fts as soon as I have time to test your nexts patchs. > 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? I'm sure you will have to create a FTS section in Postgres*.php files with some usefull methods. > 2. Am I supposed to create classes/database/Postgres83.php? I would > place function hasFTS(){return true;} there. I don't really know here. Maybe it needs some discuss as FTS could be install via contribs in pg < 8.3. But maybe in a first step, your project is to only work on fts in pg83 ? If you are only dev for 8.3, yes hasFTS(){return true;} as to be in classes/database/Postgres83.php and hasFTS(){return false;} in classes/database/Postgres.php. About classes/database/Postgres83.php, if you are the first to needing it, just do it. But we are supposed to dev it soon as we should try to release ppa with 8.3 support shortly after pg8.3 does. > I would appreciate any comments that help me to begin more serious > coding preserving all the existing practices here in the > dev-community. Imho, you are doing fine so far. Two general comments : - try to publish patch with "cvs diff -c" command. If you are including new file(s), "cvs -rcN" against a cvs version and yours is fine imho ; - I don't really remember policy about this, but maybe you could build language files you changed before diffying (do a "make english" as instance). And about this patch : - I don't know if there is any official help pages about fts so far. Maybe you should comment your 'help' entry in Misc.php until an official link appear ; - Find a revelant icon for fts...But it looks like no icon exist in the pgfoundry "pg graphics repository" (http://pgfoundry.org/docman/?group_id=1000089) for FTS :/ Maybe we should use Unknown.png to remember we miss of an icon here ? Cheers, -- Guillaume `ioguix` de Rorthais > > > 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 >> > > ------------------------------------------------------------------------ > > Index: classes/Misc.php > =================================================================== > RCS file: /cvsroot/phppgadmin/webdb/classes/Misc.php,v > retrieving revision 1.152 > diff -r1.152 Misc.php > 651a652,660 >> 'fulltext' => array ( >> 'title' => $lang['strfulltext'], >> 'url' => 'fulltext.php', >> 'urlvars' => array('subject' => 'database'), >> 'hide' => false, >> 'help' => 'pg.privilege', >> 'tree' => false, >> 'icon' => 'Privileges', >> ), > Index: lang/english.php > =================================================================== > RCS file: /cvsroot/phppgadmin/webdb/lang/english.php,v > retrieving revision 1.210 > diff -r1.210 english.php > 888a889,894 >> >> // Fulltext search >> $lang['strfulltext'] = 'Full Text Search'; >> $lang['strftsconfig'] = 'Configuration'; >> $lang['strftscreateconfig'] = 'Create configuration'; >> $lang['strftscreatedict'] = 'Create dictionary'; > Index: fulltext.php > =================================================================== > RCS file: fulltext.php > diff -N fulltext.php > 0a1,73 >> <?php >> >> /** >> * Manage fulltext configurations, dictionaries and mappings >> * >> * $Id: fulltext.php,v 1.1 2007/05/29 17:30:32 iz-sai Exp $ >> */ >> >> // Include application functions >> include_once('./libraries/lib.inc.php'); >> >> $action = (isset($_REQUEST['action'])) ? $_REQUEST['action'] : ''; >> if (!isset($msg)) $msg = ''; >> >> function doConfigurations($msg = '') { >> global $PHP_SELF, $data, $misc; >> global $lang; >> >> $misc->printTrail('database'); >> $misc->printTabs('database','fulltext'); >> $misc->printMsg($msg); >> >> $sql = "SELECT *, pg_catalog.obj_description(c.oid, 'pg_ts_cfg') AS comment FROM pg_ts_cfg AS c ORDER BY cfgname"; >> $cfgs = $data->selectSet($sql); >> >> $columns = array( >> 'configuration' => array( >> 'title' => $lang['strftsconfig'], >> 'field' => 'cfgname', >> 'url' => "#", >> ), >> 'actions' => array( >> 'title' => $lang['stractions'], >> ), >> 'comment' => array( >> 'title' => $lang['strcomment'], >> 'field' => 'comment', >> ), >> ); >> >> $actions = array( >> 'drop' => array( >> 'title' => $lang['strdrop'], >> 'url' => "#", >> 'vars' => array('cfg' => 'cfgname'), >> ), >> 'alter' => array( >> 'title' => $lang['stralter'], >> 'url' => "#", >> 'vars' => array('cfg' => 'cfgname'), >> ), >> ); >> >> $misc->printTable($cfgs, $columns, $actions, $lang['strnoschemas']); >> >> >> echo "<p><a class=\"navlink\" href=\"#\">{$lang['strftscreateconfig']}</a> |\n"; >> echo "<a class=\"navlink\" href=\"#\">{$lang['strftscreatedict']}</a>\n"; >> echo "</p>\n"; >> } >> >> $misc->printHeader($lang['strschemas']); >> $misc->printBody(); >> >> switch ($action) { >> default: >> doConfigurations(); >> break; >> } >> >> $misc->printFooter(); >> >> ?> |
From: Robert T. <xz...@us...> - 2007-06-07 02:21:45
|
On Monday 04 June 2007 05:23, Guillaume `ioguix` de Rorthais wrote: > Ivan Zolotukhin wrote: > > Hello, > > Hello and welcome on board ;) > > > 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. > > I havn't fts installed so far. But for this patch, I can give you some > comments. I will take some time to install fts as soon as I have time to > test your nexts patchs. > Just a reminder for anyone who wants to review the patch, once you have tsearch installed, the pagila database has a fulltext component to it that your can install. > > 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? > > I'm sure you will have to create a FTS section in Postgres*.php files > with some usefull methods. > yep... start with putting them in classes/database/Postgres.php in a FTS section > > 2. Am I supposed to create classes/database/Postgres83.php? I would > > place function hasFTS(){return true;} there. > > I don't really know here. Maybe it needs some discuss as FTS could be > install via contribs in pg < 8.3. > But maybe in a first step, your project is to only work on fts in pg83 ? > If you were going for support in older branches, I'd guess you would have to make this conditional based on being able to find the pg_ts_* tables in a given schema within each database (which could proove tricky) > If you are only dev for 8.3, yes hasFTS(){return true;} as to be in > classes/database/Postgres83.php and hasFTS(){return false;} in > classes/database/Postgres.php. > yep > About classes/database/Postgres83.php, if you are the first to needing > it, just do it. But we are supposed to dev it soon as we should try to > release ppa with 8.3 support shortly after pg8.3 does. > I went ahead and added an postgres83.php and an 83 docs page, feel free to modify these as needed. > > I would appreciate any comments that help me to begin more serious > > coding preserving all the existing practices here in the > > dev-community. > > Imho, you are doing fine so far. > agreed. > Two general comments : > - try to publish patch with "cvs diff -c" command. > If you are including new file(s), "cvs -rcN" against a cvs version and > yours is fine imho ; > - I don't really remember policy about this, but maybe you could build > language files you changed before diffying (do a "make english" as > instance). > not needed... if you send diffs for english.php, we can recode them on our side. > And about this patch : > - I don't know if there is any official help pages about fts so far. > Maybe you should comment your 'help' entry in Misc.php until an official > link appear ; I suppose this would pop-up once the patch gets applied in core right? > - Find a revelant icon for fts...But it looks like no icon exist in the > pgfoundry "pg graphics repository" > (http://pgfoundry.org/docman/?group_id=1000089) for FTS :/ > Maybe we should use Unknown.png to remember we miss of an icon here ? > I'll ping Niko for a new icon. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL |
From: Ivan Z. <iva...@gm...> - 2007-06-07 05:05:54
|
Hello, On 6/7/07, Robert Treat <xz...@us...> wrote: > On Monday 04 June 2007 05:23, Guillaume `ioguix` de Rorthais wrote: > > Ivan Zolotukhin wrote: > > > > > 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? > > > yep... start with putting them in classes/database/Postgres.php in a FTS > section okay, already did it > > > 2. Am I supposed to create classes/database/Postgres83.php? I would > > > place function hasFTS(){return true;} there. > > > > I don't really know here. Maybe it needs some discuss as FTS could be > > install via contribs in pg < 8.3. > > But maybe in a first step, your project is to only work on fts in pg83 ? > > If you were going for support in older branches, I'd guess you would have to > make this conditional based on being able to find the pg_ts_* tables in a > given schema within each database (which could proove tricky) Well, Oleg thinks that there should be no backward compatibility with old tsearch2 installed as a contrib, because the very sense of providing SQL interface to FTS configuration is actually an attempt to hide pg_ts_* tables from user to abstract him from these tables' structure changes by means of SQL interface. It means that in future all FTS changes that touch low level tables organization will actually keep SQL commands unchanged and Oleg is responsible for this mantainance of SQL interface. That's why he propose to rely upon new SQL syntax (CREATE FULLTEXT CONFIGURATION) and drop backward compatibility with old tsearch2 configuration tables (INSERT INTO pg_ts_cfg). Considering all this, I'd say that we firstly need to develop FTS support using 8.3 SQL syntax and then, optionally (whether in a frame of GSoC or further), support of that INSERTs into old pg_ts_* tables. > > About classes/database/Postgres83.php, if you are the first to needing > > it, just do it. But we are supposed to dev it soon as we should try to > > release ppa with 8.3 support shortly after pg8.3 does. > > I went ahead and added an postgres83.php and an 83 docs page, feel free to > modify these as needed. Oops, I've already done this couple of days ago. If I used versions system, this should not have happened. Is it possible to grant me CVS commit permission moving possibly my development to another branch? It can simplify many sync problems and code reviews. > > - I don't know if there is any official help pages about fts so far. > > Maybe you should comment your 'help' entry in Misc.php until an official > > link appear ; > > I suppose this would pop-up once the patch gets applied in core right? Docs are ready partially and right now available via http://www.sai.msu.su/~megera/postgres/fts/doc/. I suppose after patch gets applied in core these docs will migrate into main documentation. > > - Find a revelant icon for fts... > > I'll ping Niko for a new icon. That's great. To be on the safe side I also have a guy who can prepare that for us. If Niko does not help, I'll try my variant. -- Regards, Ivan |
From: Ivan Z. <iva...@gm...> - 2007-07-09 22:56:57
|
Hello again, My patch is getting bigger and bigger. Work progress is reflected at http://chernowiki.ru/index.php?node=108 and one can get a patch in its current state from there. Would appreciate any comments, notes and suggestions on the code to make it better. Regards, Ivan On 6/7/07, Ivan Zolotukhin <iva...@gm...> wrote: > Hello, > > On 6/7/07, Robert Treat <xz...@us...> wrote: > > On Monday 04 June 2007 05:23, Guillaume `ioguix` de Rorthais wrote: > > > Ivan Zolotukhin wrote: > > > > > > > 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? > > > > > yep... start with putting them in classes/database/Postgres.php in a FTS > > section > > okay, already did it > > > > > 2. Am I supposed to create classes/database/Postgres83.php? I would > > > > place function hasFTS(){return true;} there. > > > > > > I don't really know here. Maybe it needs some discuss as FTS could be > > > install via contribs in pg < 8.3. > > > But maybe in a first step, your project is to only work on fts in pg83 ? > > > > If you were going for support in older branches, I'd guess you would have to > > make this conditional based on being able to find the pg_ts_* tables in a > > given schema within each database (which could proove tricky) > > Well, Oleg thinks that there should be no backward compatibility with > old tsearch2 installed as a contrib, because the very sense of > providing SQL interface to FTS configuration is actually an attempt to > hide pg_ts_* tables from user to abstract him from these tables' > structure changes by means of SQL interface. It means that in future > all FTS changes that touch low level tables organization will actually > keep SQL commands unchanged and Oleg is responsible for this > mantainance of SQL interface. That's why he propose to rely upon new > SQL syntax (CREATE FULLTEXT CONFIGURATION) and drop backward > compatibility with old tsearch2 configuration tables (INSERT INTO > pg_ts_cfg). > > Considering all this, I'd say that we firstly need to develop FTS > support using 8.3 SQL syntax and then, optionally (whether in a frame > of GSoC or further), support of that INSERTs into old pg_ts_* tables. > > > > About classes/database/Postgres83.php, if you are the first to needing > > > it, just do it. But we are supposed to dev it soon as we should try to > > > release ppa with 8.3 support shortly after pg8.3 does. > > > > I went ahead and added an postgres83.php and an 83 docs page, feel free to > > modify these as needed. > > Oops, I've already done this couple of days ago. If I used versions > system, this should not have happened. Is it possible to grant me CVS > commit permission moving possibly my development to another branch? It > can simplify many sync problems and code reviews. > > > > - I don't know if there is any official help pages about fts so far. > > > Maybe you should comment your 'help' entry in Misc.php until an official > > > link appear ; > > > > I suppose this would pop-up once the patch gets applied in core right? > > Docs are ready partially and right now available via > http://www.sai.msu.su/~megera/postgres/fts/doc/. I suppose after patch > gets applied in core these docs will migrate into main documentation. > > > > - Find a revelant icon for fts... > > > > I'll ping Niko for a new icon. > > That's great. To be on the safe side I also have a guy who can prepare > that for us. If Niko does not help, I'll try my variant. > > -- > Regards, > Ivan > |
From: Robert T. <xz...@us...> - 2007-07-11 22:15:29
|
On Monday 09 July 2007 18:56, Ivan Zolotukhin wrote: > Hello again, > > My patch is getting bigger and bigger. Work progress is reflected at > http://chernowiki.ru/index.php?node=108 and one can get a patch in its > current state from there. Would appreciate any comments, notes and > suggestions on the code to make it better. > I took a quick look, and for the most part it looks good. One thing we will be doing in HEAD real soon is eliminating all use of $PHP_SELF, so you should probably go ahead and remove that from your patch as well (see REL_4-1-3 branch for examples if you need them). One question, AIUI there is no way of testing this patch against a working postgres short of grabbing pg cvs_head and applying the latest patch on -patches is there? -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL |
From: Ivan Z. <iva...@gm...> - 2007-07-12 08:06:06
|
Hello, On 7/12/07, Robert Treat <xz...@us...> wrote: > I took a quick look, and for the most part it looks good. One thing we will be > doing in HEAD real soon is eliminating all use of $PHP_SELF, so you should > probably go ahead and remove that from your patch as well (see REL_4-1-3 > branch for examples if you need them). ok, thanks for the note, I'll take a look at the new branch and change my code accordingly. > One question, AIUI there is no way of testing this patch against a working > postgres short of grabbing pg cvs_head and applying the latest patch > on -patches is there? Yep, this should work. I'm a bit behind it since I do not recompile my PostgreSQL I use with PPA every time FTS patch changes, but pg HEAD + patch from http://www.sai.msu.su/~megera/postgres/fts/doc/ definitely works. I'll switch to latest one from -patches soon. But Oleg thinks that since 8.3 release is a bit late, we should also support older PostgreSQL versions with tsearch2 installed anyway. This keep interfaces almost intact, but requires double work in Postgres83.php. I did not plan it before, but this is good idea since there are thousands of tsearch2 users that won't switch to 8.3 even after its release. So I hope to include this backward compatibilty in my patch soon for you to test it on usual pg installation. Regards, Ivan |
From: Robert T. <xz...@us...> - 2007-07-12 13:57:46
|
On Thursday 12 July 2007 04:06, Ivan Zolotukhin wrote: > Hello, > > On 7/12/07, Robert Treat <xz...@us...> wrote: > > I took a quick look, and for the most part it looks good. One thing we > > will be doing in HEAD real soon is eliminating all use of $PHP_SELF, so > > you should probably go ahead and remove that from your patch as well (see > > REL_4-1-3 branch for examples if you need them). > > ok, thanks for the note, I'll take a look at the new branch and change > my code accordingly. > > > One question, AIUI there is no way of testing this patch against a > > working postgres short of grabbing pg cvs_head and applying the latest > > patch on -patches is there? > > Yep, this should work. I'm a bit behind it since I do not recompile my > PostgreSQL I use with PPA every time FTS patch changes, but pg HEAD + > patch from http://www.sai.msu.su/~megera/postgres/fts/doc/ definitely > works. I'll switch to latest one from -patches soon. > OK, I've not compiled this setup recently either, since I saw Tom reviewing the patch at least, since I'm thinking what we end up with might be different, and it is surely still a moving target at this point. I saw Bruce committed some docs earlier this week though, so things must be getting close to stable (I hope!) > But Oleg thinks that since 8.3 release is a bit late, we should also > support older PostgreSQL versions with tsearch2 installed anyway. This > keep interfaces almost intact, but requires double work in > Postgres83.php. I did not plan it before, but this is good idea since > there are thousands of tsearch2 users that won't switch to 8.3 even > after its release. So I hope to include this backward compatibilty in > my patch soon for you to test it on usual pg installation. > Oh really? I think that is quite a bit harder than doing the 8.3 bits, for example, you'll need to pull some trick like we did with slony to look for a pg_ts_config table in all of the schemas, since there is no way to know where the tsearch might have been installed. What are you're feeling about committing the 8.3 FTS support into the main branch first, and then working on older tsearch2 related parts? On a side note, the way I would invision this being done is adding pre-8.3 syntax in Postgres.php, so that the Postgres83.php command would then override the older versions. You'd also need to change the hasFTS() function somewhat, to draw a distinct between built-in FTS, tsearch2, and servers where tsearch2 is not an option (7.3 and older iirc); or maybe we would have a hasFTS() and a hasTsearch2() functions... will tsearch2 be available in 8.3? AIUI it will, so we'll have to account for that as well. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL |
From: Ivan Z. <iva...@gm...> - 2007-07-19 21:29:47
|
Hello, On 7/12/07, Robert Treat <xz...@us...> wrote: > On Thursday 12 July 2007 04:06, Ivan Zolotukhin wrote: > > But Oleg thinks that since 8.3 release is a bit late, we should also > > support older PostgreSQL versions with tsearch2 installed anyway. This > > keep interfaces almost intact, but requires double work in > > Postgres83.php. I did not plan it before, but this is good idea since > > there are thousands of tsearch2 users that won't switch to 8.3 even > > after its release. So I hope to include this backward compatibilty in > > my patch soon for you to test it on usual pg installation. > > > > Oh really? I think that is quite a bit harder than doing the 8.3 bits, for > example, you'll need to pull some trick like we did with slony to look for a > pg_ts_config table in all of the schemas, since there is no way to know where > the tsearch might have been installed. What are you're feeling about > committing the 8.3 FTS support into the main branch first, and then working > on older tsearch2 related parts? I would like to commit the code, but before going into the main branch it needs to be tested more carefully and this possibly should occur after pg FTS patch settled up (i.e. one can use pg CVS HEAD to compile PostgreSQL for PPA FTS tests). I'm also preparing a test PostgreSQL+FTS+PPA installation for you all to look at it and comment for me to improve application where necessary. I'd be happy to receive a commit rights since it can simplify my development. I do not even have proper versioning of the patch (only built-in Eclipse system to store local versions) now and I lack it so much. > On a side note, the way I would invision this being done is adding pre-8.3 > syntax in Postgres.php, so that the Postgres83.php command would then > override the older versions. You'd also need to change the hasFTS() function > somewhat, to draw a distinct between built-in FTS, tsearch2, and servers > where tsearch2 is not an option (7.3 and older iirc); or maybe we would have > a hasFTS() and a hasTsearch2() functions... will tsearch2 be available in > 8.3? AIUI it will, so we'll have to account for that as well. Tsearch2 as a contrib won't be available in 8.3. But you're right in the list of problems, they do exist and I'll at least make an attempt to solve them. Regards, Ivan |
From: Ivan Z. <iva...@gm...> - 2007-08-17 13:51:18
|
Hello, I prepared public PPA installation patched with my FTS patch working over PostgreSQL 8.3devel (CVS HEAD) + FTS v0.58 patch, you can have a look at http://virtual.sai.msu.ru/~iz/ppa/ (postgres / empty password). Code is a bit outdated since I did a lot of work in the last few days, so treat it as a bare prototype without interfaces improvements. Remember also that PostgreSQL FTS patch is not stable yet and at the moment I therefore implemented only core SQL functionality without useful features I'm coding now and continue working after SoC finishes. Anyway, comments and suggestions are welcome. I'm planning to start work on support of tsearch2 in PostgreSQL <= 8.2 just after I commit (with your help) this patch in PPA (which in turn is reasonable only after PostgreSQL FTS patch will be commited, so at least several weeks from now looking at flames in -hackers). Regards, Ivan P.S. Most recent public version of the patch for review and comments as always is accessible through http://chernowiki.ru/index.php?node=108 page. On 7/20/07, Ivan Zolotukhin <iva...@gm...> wrote: > Hello, > > On 7/12/07, Robert Treat <xz...@us...> wrote: > > On Thursday 12 July 2007 04:06, Ivan Zolotukhin wrote: > > > But Oleg thinks that since 8.3 release is a bit late, we should also > > > support older PostgreSQL versions with tsearch2 installed anyway. This > > > keep interfaces almost intact, but requires double work in > > > Postgres83.php. I did not plan it before, but this is good idea since > > > there are thousands of tsearch2 users that won't switch to 8.3 even > > > after its release. So I hope to include this backward compatibilty in > > > my patch soon for you to test it on usual pg installation. > > > > > > > Oh really? I think that is quite a bit harder than doing the 8.3 bits, for > > example, you'll need to pull some trick like we did with slony to look for a > > pg_ts_config table in all of the schemas, since there is no way to know where > > the tsearch might have been installed. What are you're feeling about > > committing the 8.3 FTS support into the main branch first, and then working > > on older tsearch2 related parts? > > I would like to commit the code, but before going into the main branch > it needs to be tested more carefully and this possibly should occur > after pg FTS patch settled up (i.e. one can use pg CVS HEAD to compile > PostgreSQL for PPA FTS tests). I'm also preparing a test > PostgreSQL+FTS+PPA installation for you all to look at it and comment > for me to improve application where necessary. > > I'd be happy to receive a commit rights since it can simplify my > development. I do not even have proper versioning of the patch (only > built-in Eclipse system to store local versions) now and I lack it so > much. > > > On a side note, the way I would invision this being done is adding pre-8.3 > > syntax in Postgres.php, so that the Postgres83.php command would then > > override the older versions. You'd also need to change the hasFTS() function > > somewhat, to draw a distinct between built-in FTS, tsearch2, and servers > > where tsearch2 is not an option (7.3 and older iirc); or maybe we would have > > a hasFTS() and a hasTsearch2() functions... will tsearch2 be available in > > 8.3? AIUI it will, so we'll have to account for that as well. > > Tsearch2 as a contrib won't be available in 8.3. But you're right in > the list of problems, they do exist and I'll at least make an attempt > to solve them. > > Regards, > Ivan > |
From: Robert T. <xz...@us...> - 2007-08-21 14:17:05
|
On Friday 17 August 2007 09:51, Ivan Zolotukhin wrote: > Hello, > > I prepared public PPA installation patched with my FTS patch working > over PostgreSQL 8.3devel (CVS HEAD) + FTS v0.58 patch, you can have a > look at http://virtual.sai.msu.ru/~iz/ppa/ (postgres / empty > password). Code is a bit outdated since I did a lot of work in the > last few days, so treat it as a bare prototype without interfaces > improvements. Remember also that PostgreSQL FTS patch is not stable > yet and at the moment I therefore implemented only core SQL > functionality without useful features I'm coding now and continue > working after SoC finishes. Anyway, comments and suggestions are > welcome. > > I'm planning to start work on support of tsearch2 in PostgreSQL <= 8.2 > just after I commit (with your help) this patch in PPA (which in turn > is reasonable only after PostgreSQL FTS patch will be commited, so at > least several weeks from now looking at flames in -hackers). > Just and FYI for ppa developers who are following along, the tsearch2 bits are now officially in core. I suspect they will need some more settling over the next few days (Bruce has some docs prepared that aren't in) but we'll likely be adding this code into ppa in the next week or two. http://archives.postgresql.org/pgsql-committers/2007-08/msg00255.php -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL |