Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fDD4U-00040c-PJ for pgadmin-hackers@arkaria.postgresql.org; Mon, 30 Apr 2018 17:58:43 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fDD4T-0004QX-53 for pgadmin-hackers@arkaria.postgresql.org; Mon, 30 Apr 2018 17:58:41 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fDD4S-0004QN-J1 for pgadmin-hackers@lists.postgresql.org; Mon, 30 Apr 2018 17:58:41 +0000 Received: from mx0b-00296801.pphosted.com ([148.163.153.148]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fDD4N-0004P8-38 for pgadmin-hackers@postgresql.org; Mon, 30 Apr 2018 17:58:38 +0000 Received: from pps.filterd (m0114584.ppops.net [127.0.0.1]) by mx0b-00296801.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w3UHv0CS029181 for ; Mon, 30 Apr 2018 17:58:33 GMT Received: from mail-it0-f72.google.com (mail-it0-f72.google.com [209.85.214.72]) by mx0b-00296801.pphosted.com with ESMTP id 2hmgqghdvm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 30 Apr 2018 17:58:32 +0000 Received: by mail-it0-f72.google.com with SMTP id o143-v6so7814785itg.9 for ; Mon, 30 Apr 2018 10:58:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fKvapmIM0R59EMTjCoZAoa/ibm+37i9kxEuYcZROOwg=; b=mI570pKj3mQehIzvHQ8hBBCc3Gq36w2PSkI5eD3Y5a5lno/KMf1XTDLLmWS9HU9UoU zcv4rQ78fyflZjpg9lPhaFspHJYj6RxCCu66Sob3z7+CGvlAWegiYj2OyILf9/s11Oju YY+igz6cfpA+phAXLk4o5eOA2UrNFszFrsReYLLJsHOxU/kdeadNG9tPcgBXFgYg+H5+ v2UwVLNvESY2D/7BkKyTwbrsc5UzFFpx5S6yhiI4O/rzjKg7ToXlBL6UugZyQarYlUD5 CjzRvjMLu1b8UP5x2njrFJNRV7HMpPxX64bAp+SxFR7hR1qnPB57YeBNettnf8V/cEGA hCxA== X-Gm-Message-State: ALQs6tCPXdhdy/ON+0pKB27wu7lO7RAgQko3JXm3mpw2J4RCEAj8ORqa XkJUrZNPv5Pu3Txx/lbIc9KA0cvZwc8NyjiOW/ToAbXSb0Ucd2zugDnkIziD25poAMRy7E0MgTf 9iL1dTxm8TT6AVN1uW1Ow4nVdiE3a6/3RondiY/fADrsRuuVtutwe5s9v4yVNyuVPtfGe X-Received: by 2002:a6b:ab82:: with SMTP id u124-v6mr6665373ioe.234.1525111112096; Mon, 30 Apr 2018 10:58:32 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpgwGxLvmIoNNptGeCK3rpxybwvOklhoiDFf5eyW0u2oQKL1aFKbnKPIVHt2rKi2LXxh0UwKOpBiY6nrtij0sg= X-Received: by 2002:a6b:ab82:: with SMTP id u124-v6mr6665346ioe.234.1525111111734; Mon, 30 Apr 2018 10:58:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Joao De Almeida Pereira Date: Mon, 30 Apr 2018 17:57:56 +0000 Message-ID: Subject: Re: [pgadmin4][patch] Initial patch to decouple from ACI Tree To: Ashesh Vashi Cc: Dave Page , Anthony Emengo , Khushboo Vashi , Murtuza Zabuawala , pgadmin-hackers Content-Type: multipart/alternative; boundary="0000000000000f0d4d056b149a0c" X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-04-30_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804300173 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000000f0d4d056b149a0c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You've lost us with the last reply. We'd love to know what we'd have to do to get this patch committed. You mention that "some things are missing at some places" and that "there are missing bits". Please note that this is not a complete solution that we've offered so far. But only one step in a grander effort to effect a more cleaner, more maintainable, more testable, code base. Thanks Joao and Anthony. On Mon, Apr 30, 2018 at 11:45 AM Ashesh Vashi wrote: > On Mon, Apr 30, 2018 at 9:07 PM, Dave Page wrote: > >> >> >> On Mon, Apr 30, 2018 at 4:33 PM, Ashesh Vashi < >> ashesh.vashi@enterprisedb.com> wrote: >> >>> >>> On Mon, Apr 30, 2018 at 8:58 PM, Anthony Emengo >>> wrote: >>> >>>> I was expecting a separate layer between the tree implementation, and >>>>> aciTree adaptor. >>>>> Please find the patch for the example. >>>>> It will separate the two layers, and easy to replace with the new >>>>> implementation in future. >>>> >>>> >>>> In general, we want defer the separation of the layers for now. Even >>>> though we might assume that this is the direction we want to go in. It= 's >>>> simply too early to be making such an architectural leap. For right no= w, we >>>> just know that we need the decoupling, but don't know what if we'd nee= d the >>>> 2 layers *as implemented*. The principle we're adhering to here is the >>>> Last Responsible Moment principle, which states that you only make the >>>> changes that you feel is necessary for the given problems you're facin= g: >>>> https://blog.codinghorror.com/the-last-responsible-moment/ >>>> >>>> I would not like to see that changes in this patch. >>>>> I would like us to come up with the actual design about the hot >>>>> pluggability before going in this direction. >>>> >>>> >>>> In our point of view these 2 changes are not related. One thing is the >>>> internal code organization of the application, other thing is allowing >>>> third party to drop code in the application and it just work. These 2 >>>> should be talked separately, but the hot pluggability is not something= that >>>> will be address by this work we are doing right now. >>>> >>> Neither - it should be part of this change. >>> It should be addressed separately, and discussed. >>> >> >> I agree. As long as this work doesn't make the pluggability problem >> worse, that problem should be considered separately. >> >> So given Anthony's comments, are you happy with this patch? >> > I liked the design so far. > But - as Khushboo mentioned ealier - it is missing at some places. > I had to read through the code to understand the execution flow for some. > > And, there is still a lot missing bits, and pieces to consider for commit > in the repo. > > -- Thanks, Ashesh > >> >> >>> >>> -- Thanks, Ashesh >>> >>>> >>>> Anthony && Joao >>>> >>>> On Mon, Apr 30, 2018 at 11:03 AM, Ashesh Vashi < >>>> ashesh.vashi@enterprisedb.com> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Apr 30, 2018 at 8:30 PM, Ashesh Vashi < >>>>> ashesh.vashi@enterprisedb.com> wrote: >>>>> >>>>>> On Sat, Apr 28, 2018 at 3:55 AM, Joao De Almeida Pereira < >>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>> >>>>>>> Hi Hackers, >>>>>>> As you are aware we kept on working on the patch, so we are >>>>>>> attaching to this email a new version of the patch. >>>>>>> This new version contains all the changes in the previous one plus >>>>>>> more extractions of functions and refactoring of code. >>>>>>> >>>>>>> The objective of this patch is to create a separation between >>>>>>> pgAdmin and the ACI Tree. We are doing this because we realized tha= t at >>>>>>> this point in time we have the ACI Tree all over the code of pgAdmi= n. I >>>>>>> found a very interesting article that really talks about this: >>>>>>> https://medium.freecodecamp.org/code-dependencies-are-the-devil-35e= d28b556d >>>>>>> >>>>>>> In this patch there are some visions and ideas about the location o= f >>>>>>> the code, the way to organize it and also try to pave the future fo= r a >>>>>>> application that is stable, easy to develop on and that can be rele= ase at a >>>>>>> times notice. >>>>>>> >>>>>>> We are investing a big chunk of our time in doing this refactoring, >>>>>>> but while doing that we also try to respond to the patches sent to = the >>>>>>> mailing list. We would like the feedback from the community because= we >>>>>>> believe this is a changing point for the application. The idea is t= o change >>>>>>> the way we develop this application, instead of only correcting a b= ug of >>>>>>> developing a feature, with every commit we should correct the bug o= r >>>>>>> develop a feature but leave the code a little better than we found = it >>>>>>> (Refactoring, refactoring, refactoring). This is hard work but that= is what >>>>>>> the users from pgAdmin expect from this community of developers. >>>>>>> >>>>>>> >>>>>>> =3D=3D=3D=3D=3D=3D >>>>>>> >>>>>>> >>>>>>> >>>>>>> It is a huge patch >>>>>>> 86 files changed, 5492 inserts, 1840 >>>>>>> deletions >>>>>>> and we would like to get your feedback as soon as possible, because >>>>>>> we are continuing to work on it which means it is going to grow in = size. >>>>>>> >>>>>>> >>>>>>> At this point in time we still have 124 of 176 calls to the functio= n >>>>>>> itemData from ACITree. >>>>>>> >>>>>>> What does each patch contain: >>>>>>> 0001: >>>>>>> Very simple patch, we found out that the linter was not looking >>>>>>> into all the javascript test files, so this patch will ensure it is >>>>>>> >>>>>> Committed the patch along with the regression introduced because of >>>>>> this patch. >>>>>> >>>>>>> >>>>>>> 0002: >>>>>>> New Tree abstraction. This patch contains the new Tree that works >>>>>>> as an adaptor for ACI Tree and is going to be used on all the extra= ctions >>>>>>> that we are doing. >>>>>>> >>>>>> >>>>>> I was expecting a separate layer between the tree implementation, an= d >>>>>> aciTree adaptor. >>>>>> Please find the patch for the example. >>>>>> >>>>>> It will separate the two layers, and easy to replace with the new >>>>>> implemenation in future. >>>>>> >>>>> >>>>> Oops forgot to attach the patch. >>>>> Please find the patch attached. >>>>> >>>>> -- Thanks, Ashesh >>>>> >>>>>> >>>>>>> 0003: >>>>>>> Code that extracts, wrap with tests and replace ACI Tree >>>>>>> invocations. >>>>>>> >>>>>> There are many small cases left in the patches. >>>>>> Hence - I would like to know the TODO list created by you. >>>>>> >>>>>> e.g. When we remove any of the object from the database server, we'r= e >>>>>> not yet removing the respective node from the new implementation, an= d its >>>>>> children. >>>>>> >>>>>>> >>>>>>> We start creating new pattern for the location of Javascript file= s >>>>>>> and their structure. >>>>>>> >>>>>> I would not like to see that changes in this patch. >>>>>> I would like us to come up with the actual design about the hot >>>>>> pluggability before going in this direction. >>>>>> >>>>>>> Create patterns for creation of dialogs (backup and restore) >>>>>>> >>>>>> It's better - we don't change the directory structure at the moment. >>>>>> >>>>>> I am not against dividing the big javascript files in small chunks, >>>>>> but - I would like us to discuss first about the hot plugins design = first. >>>>>> >>>>>> -- Thanks, Ashesh >>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>>> >>>>>>> Thanks >>>>>>> Joao >>>>>>> >>>>>>> >>>>>>> On Fri, Apr 27, 2018 at 5:34 AM Ashesh Vashi < >>>>>>> ashesh.vashi@enterprisedb.com> wrote: >>>>>>> >>>>>>>> I have quite a few comments for the patch. >>>>>>>> I will send them soon. >>>>>>>> >>>>>>>> On Fri, Apr 27, 2018, 14:45 Dave Page wrote: >>>>>>>> >>>>>>>>> How is your work on this going Ashesh? Will you be committing >>>>>>>>> today? >>>>>>>>> >>>>>>>>> On Wed, Apr 25, 2018 at 8:52 AM, Dave Page >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Ashesh; you had agreed to work on this early this week. Please >>>>>>>>>> ensure you do so today. >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> >>>>>>>>>> On Tue, Apr 24, 2018 at 8:13 PM, Joao De Almeida Pereira < >>>>>>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Hackers, >>>>>>>>>>> >>>>>>>>>>> Can someone review and merge this patch? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Joao >>>>>>>>>>> >>>>>>>>>>> On Wed, Apr 18, 2018 at 10:23 AM Joao De Almeida Pereira < >>>>>>>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Hackers, >>>>>>>>>>>> Any other comment about this patch? >>>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Joao >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Apr 10, 2018 at 12:00 PM Joao De Almeida Pereira < >>>>>>>>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hello Khushboo >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Apr 9, 2018 at 1:59 AM Khushboo Vashi < >>>>>>>>>>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Joao, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have reviewed your patch and have some suggestions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Apr 7, 2018 at 12:43 AM, Joao De Almeida Pereira < >>>>>>>>>>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hello Murtuza/Dave, >>>>>>>>>>>>>>> Yes now the extracted functions are spread into different >>>>>>>>>>>>>>> files. The intent would be to make the files as small as po= ssible, and also >>>>>>>>>>>>>>> to group and name them in a way that would be easy to under= stand what each >>>>>>>>>>>>>>> file is doing without the need of opening it. >>>>>>>>>>>>>>> As a example: >>>>>>>>>>>>>>> static/js/backup will contain all the backup related >>>>>>>>>>>>>>> functionality inside of this folder we can see the file: >>>>>>>>>>>>>>> >>>>>>>>>>>>>> menu_utils.js At this moment in time we decided to group all >>>>>>>>>>>>>>> the functions that are related to the menu, but we can spli= t that also if >>>>>>>>>>>>>>> we believe it is easier to see. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> It's really very good to see the separated code for backup >>>>>>>>>>>>>> module. As we have done for backup, we would like do it for = other PG >>>>>>>>>>>>>> utilities like restore, maintenance etc. >>>>>>>>>>>>>> Considering this, we should separate the code in a way that >>>>>>>>>>>>>> some of the common functionalities can be used for other mod= ules like menu >>>>>>>>>>>>>> (as you have mentioned above), dialogue factory etc. >>>>>>>>>>>>>> Also, I think these functionalities should be in their >>>>>>>>>>>>>> respective static folder instead of pgadmin/static. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> About the location of the files. The move of the files to >>>>>>>>>>>>> pgadmin/static/js was made on purpose in order to clearly sep= arate >>>>>>>>>>>>> Javascript from python code. >>>>>>>>>>>>> The rational behind it was >>>>>>>>>>>>> - Create a clear separation between the backend and frontend >>>>>>>>>>>>> - Having Javascript code concentrated in a single place, >>>>>>>>>>>>> hopefully, will encourage to developers to look for a functio= nality, that >>>>>>>>>>>>> is already implemented in another modules, because they are r= ight there. >>>>>>>>>>>>> (When we started this journey we realized that the 'nodes' ha= ve a big >>>>>>>>>>>>> groups of code that could be shared, but because the Javascri= pt is spread >>>>>>>>>>>>> everywhere it is much harder to look for it) >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> There are some drawbacks of this separation: >>>>>>>>>>>>> - When creating a new module we will need to put the >>>>>>>>>>>>> javascript in a separate location from the backend code >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> static/js/datagrid folder contains all the datagrid related >>>>>>>>>>>>>>> functionality >>>>>>>>>>>>>>> >>>>>>>>>>>>>> Same as backup module, this should be in it's respective >>>>>>>>>>>>>> static/js folder. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Inside of the folder we can see the files: >>>>>>>>>>>>>>> get_panel_title.js is responsible for retrieving the name >>>>>>>>>>>>>>> of the panel >>>>>>>>>>>>>>> show_data.js is responsible for showing the datagrid >>>>>>>>>>>>>>> show_query_tool.js is responsible for showing the query too= l >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does this structure make sense? >>>>>>>>>>>>>>> Can you give an example of a comment that you think is >>>>>>>>>>>>>>> missing and that could help? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As a personal note, unless the algorithm is very obscure or >>>>>>>>>>>>>>> very complicated, I believe that if the code needs comments= it is a signal >>>>>>>>>>>>>>> that something needs to change in terms of naming, structur= e of the part in >>>>>>>>>>>>>>> question. This being said, I am open to add some comments t= hat might help >>>>>>>>>>>>>>> people. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> You are right, with the help of naming convention and >>>>>>>>>>>>>> structure of the code, any one can get the idea about the co= de. But it is >>>>>>>>>>>>>> very useful to understand the code >>>>>>>>>>>>>> very easily with the proper comments especially when there >>>>>>>>>>>>>> are multiple developers working on a single project. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I found some of the places where it would be great to have >>>>>>>>>>>>>> comments. >>>>>>>>>>>>>> >>>>>>>>>>>>>> - treeMenu: new tree.Tree() in a browser.js >>>>>>>>>>>>>> - tree.js (especially Tree class) >>>>>>>>>>>>>> >>>>>>>>>>>>> About the comment point I need a more clear understanding on >>>>>>>>>>>>> what kind of comments you are looking for. Because when you r= ead the >>>>>>>>>>>>> function names you understand the intent, what they are doing= . The >>>>>>>>>>>>> parameters also explain what you need to pass into them. >>>>>>>>>>>>> >>>>>>>>>>>>> If what you are looking for in these comments is the reasonin= g >>>>>>>>>>>>> being the change itself, then that should be present in the c= ommit message. >>>>>>>>>>>>> Specially because this is going to be a very big patch with a= very big >>>>>>>>>>>>> number of changes. >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>> Joao >>>>>>>>>>>>>>> =E2=80=8B >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Khushboo >>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Apr 6, 2018 at 4:48 AM Murtuza Zabuawala < >>>>>>>>>>>>>>> murtuza.zabuawala@enterprisedb.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Joao, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Patch looks good and working as expected. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I also agree with Dave, Can we please add some comments in >>>>>>>>>>>>>>>> each file which can help us to understand the flow, I'm sa= ying because now >>>>>>>>>>>>>>>> the code is segregated in so many separate files it will b= e hard to keep >>>>>>>>>>>>>>>> track of the flow from one file to another when debugging. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> Murtuza Zabuawala >>>>>>>>>>>>>>>> EnterpriseDB: http://www.enterprisedb.com >>>>>>>>>>>>>>>> The Enterprise PostgreSQL Company >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Thu, Apr 5, 2018 at 7:08 PM, Joao De Almeida Pereira < >>>>>>>>>>>>>>>> jdealmeidapereira@pivotal.io> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Khushboo, >>>>>>>>>>>>>>>>> Attached you can find both patches rebased >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Apr 5, 2018 at 6:31 AM Khushboo Vashi < >>>>>>>>>>>>>>>>> khushboo.vashi@enterprisedb.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Joao, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Can you please rebase the second patch? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Khushboo >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Apr 3, 2018 at 12:15 AM, Joao De Almeida Pereira >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Hackers, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Attached you can find the patch that will start to >>>>>>>>>>>>>>>>>>> decouple pgAdmin from ACITree library. >>>>>>>>>>>>>>>>>>> This patch is intended to be merged after 3.0, because >>>>>>>>>>>>>>>>>>> we do not want to cause any entropy or delay the releas= e, but we want to >>>>>>>>>>>>>>>>>>> start the discussion and show some code. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This job that we started is a massive tech debt chore >>>>>>>>>>>>>>>>>>> that will take some time to finalize and we would love = the help of the >>>>>>>>>>>>>>>>>>> community to do it. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *Summary of the patch:* >>>>>>>>>>>>>>>>>>> 0001 patch: >>>>>>>>>>>>>>>>>>> - Creates a new tree that will allow us to create a >>>>>>>>>>>>>>>>>>> separation between the application and ACI Tree >>>>>>>>>>>>>>>>>>> - Creates a Fake Tree (Test double, for reference on >>>>>>>>>>>>>>>>>>> the available test doubles: >>>>>>>>>>>>>>>>>>> https://martinfowler.com/bliki/TestDouble.html) that >>>>>>>>>>>>>>>>>>> can be used to inplace to replace the ACITree and also = encapsulate the new >>>>>>>>>>>>>>>>>>> tree behavior on our tests >>>>>>>>>>>>>>>>>>> - Adds tests for all the tree functionalities >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 0002 patch: >>>>>>>>>>>>>>>>>>> - Extracts, refactors, adds tests and remove dependenc= y >>>>>>>>>>>>>>>>>>> from ACI Tree on: >>>>>>>>>>>>>>>>>>> - getTreeNodeHierarchy >>>>>>>>>>>>>>>>>>> - on backup.js: menu_enabled, menu_enabled_server, >>>>>>>>>>>>>>>>>>> start_backup_global_server, backup_objects >>>>>>>>>>>>>>>>>>> - on datagrid.js: show_data_grid, get_panel_title, >>>>>>>>>>>>>>>>>>> show_query_tool >>>>>>>>>>>>>>>>>>> - Start using sprintf-js as Underscore.String is >>>>>>>>>>>>>>>>>>> deprecating sprintf function >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This patch represents only 10 calls to ACITree.itemData >>>>>>>>>>>>>>>>>>> out of 176 that are spread around our code >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *In Depth look on the process behind the patch:* >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> We started writing this patch with the idea that we nee= d >>>>>>>>>>>>>>>>>>> to decouple pgAdmin4 from ACITree, because ACITree is n= o longer supported, >>>>>>>>>>>>>>>>>>> the documentation is non existent and ACITree is no lon= ger being actively >>>>>>>>>>>>>>>>>>> developed. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Our process: >>>>>>>>>>>>>>>>>>> 1. We "randomly" selected a function that is part of th= e >>>>>>>>>>>>>>>>>>> ACITree. From this point we decided to replace that fun= ction with our own >>>>>>>>>>>>>>>>>>> version. The function that we choose was "itemData". >>>>>>>>>>>>>>>>>>> The function gives us all the "data" that a specific >>>>>>>>>>>>>>>>>>> node of the tree find. >>>>>>>>>>>>>>>>>>> Given in order to replace the tree we would need to hav= e >>>>>>>>>>>>>>>>>>> a function that would give us the same information. We = had 2 options: >>>>>>>>>>>>>>>>>>> a) Create a tree with a function called itemData >>>>>>>>>>>>>>>>>>> Pros: >>>>>>>>>>>>>>>>>>> - At first view this was the simpler solution >>>>>>>>>>>>>>>>>>> - Would keep the status quo >>>>>>>>>>>>>>>>>>> Cons: >>>>>>>>>>>>>>>>>>> - Not a OOP approach >>>>>>>>>>>>>>>>>>> - Not very flexible >>>>>>>>>>>>>>>>>>> b) Create a tree that would return a node given an ID >>>>>>>>>>>>>>>>>>> and then the node would be responsible for giving it's = data. >>>>>>>>>>>>>>>>>>> Pros: >>>>>>>>>>>>>>>>>>> - OOP Approach >>>>>>>>>>>>>>>>>>> - More flexible and we do not need to bring the tree >>>>>>>>>>>>>>>>>>> around, just a node >>>>>>>>>>>>>>>>>>> Cons: >>>>>>>>>>>>>>>>>>> - Break the current status quo >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Given these 2 options we decided to go for a more OOP >>>>>>>>>>>>>>>>>>> approach creating a Tree and a TreeNode classes, that i= n the future will be >>>>>>>>>>>>>>>>>>> renamed to ACITreeWrapper and TreeNode. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2. After we decided on the starting point we searched >>>>>>>>>>>>>>>>>>> for occurrences of the function "itemData" and we found= out that there were >>>>>>>>>>>>>>>>>>> 303 occurrences of "itemData" in the code and roughly 1= 76 calls to the >>>>>>>>>>>>>>>>>>> function itself (some of the hits were variable names). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 3. We selected the first file on the search and found >>>>>>>>>>>>>>>>>>> the function that was responsible for calling the itemD= ata function. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 4. Extracted the function to a separate file >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 5. Wrap this function with tests >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 6. Refactor the function to ES6, give more declarative >>>>>>>>>>>>>>>>>>> names to variables and break the functions into smaller= chunks >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 7. When all the tests were passing we replaced ACITree >>>>>>>>>>>>>>>>>>> with our Tree >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 8. We ensured that all tests were passing >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 9. Remove function from the original file and use the >>>>>>>>>>>>>>>>>>> new function >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 10. Ensure everything still works >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 11. Find the next function and execute from step 4 unti= l >>>>>>>>>>>>>>>>>>> all the functions are replaced, refactored and tested. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> As you can see by the process this is a pretty huge >>>>>>>>>>>>>>>>>>> undertake, because of the number of calls to the functi= on. This is just the >>>>>>>>>>>>>>>>>>> first step on the direction of completely isolating the= ACITree so that we >>>>>>>>>>>>>>>>>>> can solve the problem with a large number of elements o= n the tree. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *What is on our radar that we need to address:* >>>>>>>>>>>>>>>>>>> - Finish the complete decoupling of the ACITree >>>>>>>>>>>>>>>>>>> - Performance of the current tree implementation >>>>>>>>>>>>>>>>>>> - Tweak the naming of the Tree class to explicitly tel= l >>>>>>>>>>>>>>>>>>> us this is to use only with ACITree. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>> Joao >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Dave Page >>>>>>>>>> Blog: http://pgsnake.blogspot.com >>>>>>>>>> Twitter: @pgsnake >>>>>>>>>> >>>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>>>>>> The Enterprise PostgreSQL Company >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Dave Page >>>>>>>>> Blog: http://pgsnake.blogspot.com >>>>>>>>> Twitter: @pgsnake >>>>>>>>> >>>>>>>>> EnterpriseDB UK: http://www.enterprisedb.com >>>>>>>>> The Enterprise PostgreSQL Company >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> -- >> Dave Page >> Blog: http://pgsnake.blogspot.com >> Twitter: @pgsnake >> >> EnterpriseDB UK: http://www.enterprisedb.com >> The Enterprise PostgreSQL Company >> > > --0000000000000f0d4d056b149a0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You've lost us with the last reply. We'd love to k= now what we'd have to do to get this patch committed. You mention that = "some things are missing at some places" and that "there are= missing bits". Please note that this is not a complete solution that = we've offered so far. But only one step in a grander effort to effect a= more cleaner, more maintainable, more testable, code base.

<= div>Thanks
Joao and Anthony.

On Mon, Apr 30, 2018 at 11:45 AM Ashesh Vashi <ashesh.vashi@enterprisedb.co= m> wrote:
<= div class=3D"gmail_extra">
On Mon, Apr 30, 2018 at 9:07 PM, Dave = Page <dpage@pgadmin.org> wrote:
<= /div>


On= Mon, Apr 30, 2018 at 4:33 PM, Ashesh Vashi <ashesh.vashi@en= terprisedb.com> wrote:

On Mon, Apr 30, 2018 at 8:58 PM, Anthony Emengo <aemengo@pivotal.io= > wrote:
I was expecting a separate layer between t= he tree implementation, and aciTree adaptor.
Please find the patch for t= he example.
It will separate the two layers, and easy to replace = with the new implementation in future.=C2=A0

In general, we want defer the separation of the layers for now. Eve= n though we might assume that this is the direction we want to go in. It= 9;s simply too early to be making such an architectural leap. For right now= , we just know that we need the decoupling, but don't know what if we&#= 39;d need the 2 layers as implemented. The principle we'r= e adhering to here is the Last Responsible Moment principle, which states t= hat you only make the changes that you feel is necessary for the given prob= lems you're facing:=C2=A0https://blog.codinghorror.com/th= e-last-responsible-moment/

I would not like to see that changes in this pat= ch.
I would like us to come up with the actual design about the hot plug= gability before going in this direction.

In ou= r point of view these 2 changes are not related. One thing is the internal = code organization of the application, other thing is allowing third party t= o drop code in the application and it just work. These 2 should be talked s= eparately, but the hot pluggability is not something that will be address b= y this work we are doing right now.
Neither - it should be part of this change.
It should be addre= ssed separately, and discussed.
I agree. As long as this work doesn't make the plug= gability problem worse, that problem should be considered separately.
=

So given Anthony's comments, are you happy with thi= s patch?
I liked the design so far= .
But - as Khushboo mentioned ealier - it is missing at some plac= es.
I had to read through the code to understand the execution fl= ow for some.

And, there is still a lot missing= bits, and pieces to consider for commit in the repo.

<= div>-- Thanks, Ashesh
=
=C2=A0
-- Thanks, Ashesh=C2=A0

Anthony && J= oao

On Mon, Apr 30, 2018 at 11:03 AM, Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:



On Mon, Apr 30, 2018 at 8:30 PM, Ashes= h Vashi <ashesh.vashi@enterprisedb.com> wrote:
=
On Sat, Apr 28, 2018 at = 3:55 AM, Joao De Almeida Pereira <jdealmeidapereira@pivotal.io<= /a>> wrote:
Hi Hackers,
As you are aware we kept on working on the patch, so we are attachi= ng to this email a new version of the patch.
This new version contains a= ll the changes in the previous one plus more extractions of functions and r= efactoring of code.

The objective of this patch is to create a separ= ation between pgAdmin and the ACI Tree. We are doing this because we realiz= ed that at this point in time we have the ACI Tree all over the code of pgA= dmin. I found a very interesting article that really talks about this: https://medium.freecodecamp.org/code-dependencie= s-are-the-devil-35ed28b556d

In this patch there are some visions and ideas about t= he location of the code, the way to organize it and also try to pave the fu= ture for a application that is stable, easy to develop on and that can be r= elease at a times notice.

We are investing a big = chunk of our time in doing this refactoring, but while doing that we also t= ry to respond to the patches sent to the mailing list. We would like the fe= edback from the community because we believe this is a changing point for t= he application. The idea is to change the way we develop this application, = instead of only correcting a bug of developing a feature, with every commit= we should correct the bug or develop a feature but leave the code a little= better than we found it (Refactoring, refactoring, refactoring). This is h= ard work but that is what the users from pgAdmin expect from this community= of developers.


=3D=3D=3D=3D=3D=3D<= /div>



It is a huge patch
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 86 files changed, 5492 inserts, 1840 deletions
=
and we would like to get your feedback as soon as possible, beca= use we are continuing to work on it which means it is going to grow in size= .=C2=A0


At this point in time we st= ill have 124 of 176 calls to the function itemData from ACITree.

Wha= t does each patch contain:
0001:
=C2=A0 Very simple patch, we= found out that the linter was not looking into all the javascript test fil= es, so this patch will ensure it is
Committed the patch along with the regression introduced because o= f this patch.=C2=A0

0002:
=C2=A0 New Tree abstraction. This patc= h contains the new Tree that works as an adaptor for ACI Tree and is going = to be used on all the extractions that we are doing.

I was expecting a separate layer between = the tree implementation, and aciTree adaptor.
Please find the pat= ch for the example.

It will separate the two layer= s, and easy to replace with the new implemenation in future.=C2=A0

Oops forgot to a= ttach the patch.
Please find the patch attached.

-- Thanks, Ashesh=C2=A0

0003:
=C2=A0 Code that= extracts, wrap with tests and replace ACI Tree invocations.
There are many small cases left in the pa= tches.
Hence - I would like to know the TODO list created by you.=

e.g. When we remove any of the object from the da= tabase server, we're not yet removing the respective node from the new = implementation, and its children.=C2=A0
=C2=A0
=C2=A0 We start cre= ating new pattern for the location of Javascript files and their structure.=
I would not like to see th= at changes in this patch.
I would like us to come up with the act= ual design about the hot pluggability before going in this direction.=C2=A0=
= =C2=A0 Create patterns for creation of dialogs (backup and restore)
It's better - we don't cha= nge the directory structure at the moment.

I am no= t against dividing the big javascript files in small chunks, but - I would = like us to discuss first about the hot plugins design first.

=
-- Thanks, Ashesh=C2=A0
=C2=A0
=C2=A0=C2=A0

Thanks
Joao
<= /div>


On Fri, Apr 27, 2018= at 5:34 AM Ashesh Vashi <ashesh.vashi@enterprisedb.com> wrote:
=
I have quite a few comment= s for the patch.
I will send them soon.=C2=A0
<= br>
On Fri, Apr 27, 2018, 14:45 = Dave Page <dpage@= pgadmin.org> wrote:
How is your work on this going Ashesh? Will you be committing toda= y?

On Wed, A= pr 25, 2018 at 8:52 AM, Dave Page <dpage@pgadmin.org> wrote:
Ashe= sh; you had agreed to work on this early this week. Please ensure you do so= today.

Thanks.

On Tue, Apr 24, 2018 at 8:13 PM, Joao De Almeida Perei= ra <jdealmeidapereira@pivotal.io> wrote:
Hi Hackers,
Can someone review and merge this patch?

Thanks
Joao

On Wed, Apr 18, 2018 at 10:23 AM Joao De Almeida Pereira <jdealmeidapereira@pivotal.io> wrote:
Hi Hackers,
Any other comment about th= is patch?

Thanks
= Joao

On Tue, Apr= 10, 2018 at 12:00 PM Joao De Almeida Pereira <jdealmeidaperei= ra@pivotal.io> wrote:
Hello Khushboo

On Mon, Apr 9, 20= 18 at 1:59 AM Khushboo Vashi <khushboo.vashi@enterprisedb.c= om> wrote:
Hi Joao,

I h= ave reviewed your patch and have some suggestions.

On Sat, Apr 7, 2018 at 12:43 AM, Joao De Almeida Pereira <jdealmeidapereira@pivotal.io> wrote:

Hello Murtuza/Dave,
Yes now the extra= cted functions are spread into different files. The intent would be to make= the files as small as possible, and also to group and name them in a way t= hat would be easy to understand what each file is doing without the need of= opening it.
As a example:
static/js/backup w= ill contain all the backup related functionality inside of this folder we c= an see the file:

menu_utils.js At this moment in time we deci= ded to group all the functions that are related to the menu, but we can spl= it that also if we believe it is easier to see.

It's really very good to see the separated code fo= r backup module. As we have done for backup, we would like do it for other = PG utilities like restore, maintenance etc.
Considering this, we should= separate the code in a way that some of the common functionalities can be = used for other modules=C2=A0 like menu (as you have mentioned above), dialo= gue factory etc.
Also, I think these functionalities should be in their= respective static folder instead of pgadmin/static.

About the = location of the files. The move of the files to pgadmin/static/js was made = on purpose in order to clearly separate Javascript from python code.
<= div>The rational behind it was
- Create a clear separation betwee= n the backend and frontend
- Having Javascript code concentrated = in a single place, hopefully, will encourage to developers to look for a fu= nctionality, that is already implemented in another modules, because they a= re right there. (When we started this journey we realized that the 'nod= es' have a big groups of code that could be shared, but because the Jav= ascript is spread everywhere it is much harder to look for it)


There are some drawbacks of this separation= :
- When creating a new module we will need to put the javascript= in a separate location from the backend code=C2=A0=C2=A0
=
=C2=A0
=C2=A0

static/js/datagrid folder contains all the datagrid related functionality

Same as backup module,=C2=A0 this should b= e in it's respective static/js folder.

Inside of the folder we can see the files:
get_panel_title.js is responsible for retrieving the n= ame of the panel
show_data.js is responsible for= showing the datagrid
show_query_tool.js is resp= onsible for showing the query tool

Does this structure make sense?
Can yo= u give an example of a comment that you think is missing and that could hel= p?

As a personal note, unless the algorithm = is very obscure or very complicated, I believe that if the code needs comme= nts it is a signal that something needs to change in terms of naming, struc= ture of the part in question. This being said, I am open to add some commen= ts that might help people.

Y= ou are right, with the help of naming convention and structure of the code,= any one can get the idea about the code. But it is very useful to understa= nd the code=C2=A0
very easily with the proper comments especially= when there are multiple developers working on a single project.
=
I found some of the places where it would be great to have c= omments.

- treeMenu: new tree.Tree()=C2=A0 in a br= owser.js
- tree.js=C2=A0 (especially Tree class)
About the comment point I need a more clear understanding on what kin= d of comments you are looking for. Because when you read the function names= you understand the intent, what they are doing. The parameters also explai= n what you need to pass into them.

If what you are= looking for in these comments is the reasoning being the change itself, th= en that should be present in the commit message. Specially because this is = going to be a very big patch with a very big number of changes.
=

Thanks
Joao

=E2=80=8B

Thanks,
Khushboo=C2=A0
=
<= /div>

On Fri, Apr 6, 2018 at 4:48 AM Murtuza Zabuawala <mur= tuza.zabuawala@enterprisedb.com> wrote:
Hi Joao,

Patch looks good and working= as expected.

I also agree with Dave, Can we please add some comments in each = file which can help us to understand the flow, I'm saying because now t= he code is segregated in so many separate files it will be hard to keep tra= ck of the flow from one file to another when debugging.


--
Regards,
= Murtuza Zabuawala
E= nterpriseDB:=C2=A0http://www.enterprisedb.com
The Ente= rprise PostgreSQL Company

=

On Thu, Apr 5, 2018 at 7:08 PM, Joao De Alme= ida Pereira <jdealmeidapereira@pivotal.io> wrote:
Hi Khushboo,
Attached you can find both patches rebased<= /div>

Thanks


Hi Joao,
<= br>
Can you please rebase the second patch?

<= div>Thanks,
Khushboo


On Tue, Apr 3, 2018 at 1= 2:15 AM, Joao De Almeida Pereira <jdealmeida= pereira@pivotal.io> wrote:
Hi Hackers,

Attached= you can find the patch that will start to decouple pgAdmin from ACITree li= brary.
This patch is intended to be merged after 3.0, because we = do not want to cause any entropy or delay the release, but we want to start= the discussion and show some code.

This job that = we started is a massive tech debt chore that will take some time to finaliz= e and we would love the help of the community to do it.

Summary of the patch:
0001 patch:=C2=A0
= =C2=A0- Creates a new tree that will allow us to create a separation betwee= n the application and ACI Tree
=C2=A0- Creates a Fake Tree (Test = double, for reference on the available test doubles:=C2=A0https://martinfowler.com/bliki/TestDouble.html) that can be used to= inplace to replace the ACITree and also encapsulate the new tree behavior = on our tests
=C2=A0- Adds tests for all the tree functionalities<= /div>

0002 patch:
=C2=A0- Extracts, refactors,= adds tests and remove dependency from ACI Tree on:
- getTreeNodeHi= erarchy
- on backup.js: menu_enabled, menu_enabled_server, start_ba= ckup_global_server, backup_objects
- on datagrid.js: show_data_grid,= get_panel_title, show_query_tool
- Start using sprintf-js as Underscor= e.String is deprecating sprintf function
=C2=A0=C2=A0
Thi= s patch represents only 10 calls to ACITree.itemData out of 176 that are sp= read around our code


In D= epth look on the process behind the patch:

We = started writing this patch with the idea that we need to decouple pgAdmin4 = from ACITree, because ACITree is no longer supported, the documentation is = non existent and ACITree is no longer being actively developed.
<= br>
Our process:
1. We "randomly" selected a = function that is part of the ACITree. From this point we decided to replace= that function with our own version. The function that we choose was "= itemData".
The function gives us all the "data" th= at a specific node of the tree find.
Given in order to replace th= e tree we would need to have a function that would give us the same informa= tion. We had 2 options:
=C2=A0 a) Create a tree with a function c= alled itemData
Pros:
=C2=A0- At first view this was the= simpler solution
=C2=A0- Would keep the status quo
Cons:
=C2=A0- Not a OOP approach
=C2=A0- Not very flexible
= =C2=A0 b) Create a tree that would return a node given an ID and then the n= ode would be responsible for giving it's data.
Pros:=C2=A0
=C2=A0- OOP Approach
=C2=A0- More flexible and we do not = need to bring the tree around, just a node
Cons:
=C2=A0= - Break the current status quo

Given these 2 optio= ns we decided to go for a more OOP approach creating a Tree and a TreeNode = classes, that in the future will be renamed to ACITreeWrapper and TreeNode.=

2. After we decided on the starting point we sear= ched for occurrences of the function "itemData" and we found out = that there were 303 occurrences of "itemData" in the code and rou= ghly 176 calls to the function itself (some of the hits were variable names= ).

3. We selected the first file on the search and= found the function that was responsible for calling the itemData function.=

4. Extracted the function to a separate file

5. Wrap this function with tests

<= div>6. Refactor the function to ES6, give more declarative names to variabl= es and break the functions into smaller chunks

7. = When all the tests were passing we replaced ACITree with our Tree

8. We ensured that all tests were passing

9. Remove function from the original file and use the new function<= /div>

10. Ensure everything still works

11. Find the next function and execute from step 4 until all the f= unctions are replaced, refactored and tested.

As y= ou can see by the process this is a pretty huge undertake, because of the n= umber of calls to the function. This is just the first step on the directio= n of completely isolating the ACITree so that we can solve the problem with= a large number of elements on the tree.

What i= s on our radar that we need to address:
=C2=A0- Finish the co= mplete decoupling of the ACITree
=C2=A0- Performance of the curre= nt tree implementation
=C2=A0- Tweak the naming of the Tree class= to explicitly tell us this is to use only with ACITree.


Thanks
Joao






<= /div>--
D= ave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enter= prise PostgreSQL Company



--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.c= om
The Enterprise PostgreSQL Company







--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

Enterpris= eDB UK: http://ww= w.enterprisedb.com
The Enterprise PostgreSQL Company

--0000000000000f0d4d056b149a0c--