Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fSKDo-0007Ke-Vb for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jun 2018 10:38:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fSKDn-0007Qi-Qw for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jun 2018 10:38:47 +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 1fSKBQ-0003sg-AN for pgadmin-hackers@lists.postgresql.org; Mon, 11 Jun 2018 10:36:20 +0000 Received: from mail-ot0-x244.google.com ([2607:f8b0:4003:c0f::244]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fSKBM-0005Tl-6T for pgadmin-hackers@postgresql.org; Mon, 11 Jun 2018 10:36:18 +0000 Received: by mail-ot0-x244.google.com with SMTP id w9-v6so17672621otj.7 for ; Mon, 11 Jun 2018 03:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jn+MojedCVpeCkyHo78yHyAoJGq0lOcFGS7UoeYkDc0=; b=TSA87cU0CK2Q4uJLdr0kKyxQJej4K5fczFpDm0iu5EYPMOpaG9rCZVNXVlfUGYhlBO sxZxCkFj116KY8Bum+9uFm4AwTsvfkK8pqdAcKYb4Tzpw0DOUaeRyySpnLdisL2WTT7T OUYxkCkU609nyrSJpPUbyfRBX2Q1AyF7xEGxINuOI/3DX6XPqGVk0jF9nqe34qwsK2qX jGW/nRubfNNCsD/RbcuWWSzuJLxA1IprR4RASpVACnPWdj/F4ow6hSdiLYxX7rHsZTpk Up8ChMYI5+7wv+emoJRvHKlBhN3lJXRm9K81kmuQjIOL9FO0TPvAukUo+ck3wOY1P8wy +3CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jn+MojedCVpeCkyHo78yHyAoJGq0lOcFGS7UoeYkDc0=; b=uUxPsUnCVtDZa8+5thg2OieImV4dpedy0ADU0dxoLi8F/hIeEJfPYo4gnGo9ZRECeq bI4YS5n9ngJmc9MLTBA5u0aikWsLQQLcdsPVLesJ5sVLrfMREJIAtd+/dPH1f0iRTmSY 65oE81BhnyhDqmvYI0JHxwEo0D9UtD5RqZ8t9MWUo7JEUp+R/fpAkA4nclhLVbgQPT0/ O0fdiu6/DQfAwQ9hhtWhIRcI8+U1wyXiVZRjMx495gp0mWcF5F8CiS1MEQtdy8LO1GI8 XR1vTo9ysWhWHt3NpV2oXVHxE+LowBKoHieMJlfNbHCCi1bbooY78i+XInXwoIFhNxe7 RsXw== X-Gm-Message-State: APt69E1uGdcOT5H00D+mwFaPhxyiOYPEf+b8/RRoUnfdVbT554aJHoB7 NzH1mUwYWGyLgz0rgncQ+8LF7L50SEO4YnqSotTp6A== X-Google-Smtp-Source: ADUXVKIYp1pW5795USXIx84a/bWi738PsavkHQAFkLF1ysgUU30JXpG5AVc6vrpksMeWVnWFmATtf3Q8gChyP98AAKQ= X-Received: by 2002:a9d:86c:: with SMTP id 99-v6mr10051757oty.226.1528713373273; Mon, 11 Jun 2018 03:36:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7a54:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 03:35:52 -0700 (PDT) In-Reply-To: References: From: Ashesh Vashi Date: Mon, 11 Jun 2018 16:05:52 +0530 Message-ID: Subject: Re: [pgadmin4][patch] Initial patch to decouple from ACI Tree To: Joao De Almeida Pereira Cc: Dave Page , Anthony Emengo , Khushboo Vashi , Murtuza Zabuawala , pgadmin-hackers Content-Type: multipart/alternative; boundary="00000000000093e58a056e5b5114" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --00000000000093e58a056e5b5114 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 11, 2018 at 3:59 PM, Ashesh Vashi wrote: > Hi Team, > > On Sat, May 5, 2018 at 3:31 AM, Joao De Almeida Pereira < > jdealmeidapereira@pivotal.io> wrote: > >> *...* >> 3. Start the discussion on application architecture >> >> Why should we care about location of files inside a our application? >> >> Why is this way better the another? >> >> These are 2 good questions that have very lengthy answers. Trying to mor= e >> or less summarize the answers we care about >> the location of the files, because we want our application to communicat= e >> intent and there are always pros and cons >> on all the decisions that we make. >> > To be honest, it depends on how do you see the application, and its > expectations. > That question leads me to another question "What do we want from pgAdmin > 4?" > > At this point the application structure follows our menu, this approach >> eventually make is easier to follow the code >> but at the same time if the menu changes down the line, will we change >> the structure of our folders? >> > To be honest not menu driven. (Probably a wrong choice of word 'Menu'.) > But - only under 'browser' (You can also call it object browser/tree), it > is driven by the database object relation model. > And, each module maintains the parent-child relationship. > > >> The proposal that we do with the last diff of this patch is to change to >> a structure that slices vertically the >> application. This way we can understand intent behind the code and more >> easily find what we are looking for. >> > In the current structure if you want to see the tables code you need to g= o >> to >> pgAdmin/browser/server_groups/servers/databases/schemas/tables/ this is >> a huge path to remember and to get to. What >> do we win with this? >> > I agree - it is too deep structure. > But - it gives me the idea what's the structure of the database objection > relationship. > > Does it hurt, I would say no? > Because - as a database developer, I know whats the relationship of > objects, and where I can find them. > (Until I heard Dave saying it is about to touch the limit of maximum file > system path.) > > So - there is a scope for improvement there, we can leave *live* without the object relations (but - limited to the object browser I think). > > >> If we open pgAdmin we know which nodes to click in order to get to >> tables. But for development >> every time that you are looking for a specific functionality you need to >> run the application, navigate the menu so that >> you know where you can find the code. This doesn=E2=80=99t sound very ap= pealing. >> > What if our structure would look like this: >> >> - web >> - tables >> - controller >> - get_nodes.py >> - get_sql.py >> - __init__.py >> - frontend >> - component >> - ddl_component.js >> - services >> - table-service.js >> - schemas >> - servers >> - .... >> >> I think - there is nothing wrong with the current module structure. It i= s > more appealing to me than the above one. > The python package contains the backend code, and static contains all you= r > frontend. > > I am not saying, we should not change anything. > We can definitely divide them in smaller chunks for both backend, and > frontend side. > > This would saves us time because all the information that we need is what >> are we working on and everything is right there. >> Menu driven structure Intent Driven Structure >> *Pros:* *Pros:* >> Already in place Explicitly shows features >> Self contained features Self contained features >> Support for drop in features Support for drop in features >> *Cons:* *Cons:* >> Follows the menu, and it could change Need to change current code >> Hard to find features Some additional plumbing might be needed >> Drop in features need to be placed in a specific location according to >> the menu location >> >> What are your thought about this architecture? >> > I am not a fan of flat file structure in application. > There are many reasons - why we need namespace in C++, same applies here. > > Let me start from the question "What do we want from pgAdmin 4?" > * A object browser > * Miscallenous operations associated with the object shown in the object > browser > + Reversed Enginering query (if any) > + Properties Viewer > + Edit/Create Viewer > + Staticis > + List of dependencies > + List of dependents > * Query tool > * Data Viewer (table/view) > * Function debugger > * Extendability/Pluggability > > According to me - these as the intent of the application, and not objects > assiciated with them. > > I do agree, there is no boundry (or, very thin) between data & > presentation at the moment. > We can start from there. > > I can think of the following directory structure ( which is not too > different from the current, but - still will give the developers a lot mo= re > comfort as per your complain :-) ). > >> pgadmin/ >> - database_objects/ >> - server/ >> - __init__.py >> - create.py >> - get.py >> - sql.py >> - update.py >> - static/ >> - img/ >> - server.svg >> - server_bad.svg >> - javascripts/ >> - server.js >> - ui_schema.js >> - database/ >> - templates >> ... >> ... >> + schema/ >> ... >> - tests/ >> - api/ >> ... >> - gui/ >> ... >> - karma/ >> ... >> - browser/ >> + pgagents/ >> - server_groups/ >> - servers/ >> - databases/ >> - __init__.py >> - node.py >> - schemas >> ... >> ... >> ... >> ... >> + tests/ >> - tools/ >> + sqleditor/ >> + dataviewer/ >> + debugger/ >> - misc/ >> + sql/ >> + statistics/ >> ... >> >> NOTE: > We also need to think about the facts that. > These changes may lead to a lot of night mare packagers to make changes i= n > the installers in upgrade mode. > > Also - when I say pluggability/extendability, we should be able to create > plugins on top of pgAdmin 4. > Just take an example of this feature (Geospatial Query Viewer) > > . > > I think - it is best implemented as an plugin, as not every pgAdmin user > will benificiary. > We need ability to load the modules as pluggable module same as we used t= o > have before we introduced the webpack to bundle everything as modules. > We also need to start thinking about it. > > -- Thanks, Ashesh > > Around minute 7 of this video >> Uncle Bob shows an >> application written >> in rails to talk about architecture. It is a long KeyNote if you are >> curious I would advise you to see the full video. >> His approach to architecture of the application is pretty interesting. >> > > > --00000000000093e58a056e5b5114 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= div style=3D"margin:0pt 0pt 8px">On Mon, Jun 11, 2018 at 3:59 PM, Ashesh Va= shi <ashesh.vashi@enterprisedb.com> wrote:
Hi Team,

On Sat, May 5, 2018 at 3:31 AM, Joao De Alme= ida Pereira <jdealmeidapereira@pivotal.io> wrote:=

...

3. Start the discussion on application architecture

Why should we care about location of file= s inside a our application?

Why is this way better the another?

These are 2 good questions that have very= lengthy answers. Trying to more or less summarize the answers we care abou= t
the location of the files, because we want our application to communic= ate intent and there are always pros and cons
on all the decisions that = we make.

To be honest, it depends o= n how do you see the application, and its expectations.
That ques= tion leads me to another question "What do we want from pgAdmin 4?&quo= t;

At this point the application structure f= ollows our menu, this approach eventually make is easier to follow the code=
but at the same time if the menu changes down the line, will we change = the structure of our folders?

To be= honest not menu driven. (Probably a wrong choice of word 'Menu'.)<= /div>
But - only under 'browser' (You can also call it object b= rowser/tree), it is driven by the database object relation model.
And, each module maintains the parent-child relationship.
=C2=A0

The proposal that we do with the last dif= f of this patch is to change to a structure that slices vertically the
a= pplication. This way we can understand intent behind the code and more easi= ly find what we are looking for.

In the current structure if you want to s= ee the tables code you need to go to
pgAdmin/browser/se= rver_groups/servers/databases/schemas/tables/ this is a hu= ge path to remember and to get to. What
do we win with this?

I agree - it is too deep structure.
= But - it gives me the idea what's the structure of the database objecti= on relationship.

Does it hurt, I would say no?
Because - as a database developer, I know whats the relationship of = objects, and where I can find them.
(Until I heard Dave saying it= is about to touch the limit of maximum file system path.)

=C2=A0
So - th= ere is a scope for improvement there, we can leave live without the object relations (but - limited to the object br= owser I think).
=C2=A0
=C2=A0
=

If we open pgAdmin we know which nodes t= o click in order to get to tables. But for development
every time that y= ou are looking for a specific functionality you need to run the application= , navigate the menu so that
you know where you can find the code. This d= oesn=E2=80=99t sound very appealing.

What if our structure would look like thi= s:

 - =
web
   - tables
     - controller
       - get_nodes.py
       - get_sql.py
       - __init__.py
     - frontend
        - component
            - ddl_component.js
        - services
            - table-service.js
   - schemas
   - servers
   - ....

I think - there is nothing wrong with the current module struc= ture. It is more appealing to me than the above one.
The python p= ackage contains the backend code, and static contains all your frontend.

I am not saying, we should not change anything.
We can definitely divide them in smaller chunks for both backend, and= frontend side.=C2=A0

This would= saves us time because all the information that we need is what are we work= ing on and everything is right there.

Menu dri= ven structure Intent D= riven Structure
Pros: Pros:
Already in place Explicitly shows features
Self contained features Self contained features
Support for drop in features Support for drop in features
Cons: Cons:
Follows the menu, and it could change Need to change current code
Hard to find features Some additional plumbing might be needed
Drop in features need to be placed in a specific location a= ccording to the menu location

What are your thought about this architec= ture?

I am not a fan of flat file s= tructure in application.
There are many reasons - why we need nam= espace in C++, same applies here.

Let me start fro= m the question "What do we want from pgAdmin 4?"=C2=A0
* A object browser
* Miscallenous operations associated = with=C2=A0the object shown in the object browser
=C2=A0 = + Reversed Enginering query=C2=A0(if any)
= =C2=A0 + Properties Viewer
=C2=A0 + Edit/Create Viewer
= =C2=A0 + Staticis
=C2=A0 + List of dependencies
=C2=A0 = + List of dependents
* Query tool
* Data Viewer (table/= view)
* Function debugger
* Extendability/Pluggability<= /div>

According to me - these as the intent of the appli= cation, and not objects assiciated with them.

= I do agree, there is no boundry (or, very thin) between data & presenta= tion at the moment.
We can start from there.

=
I can think of the following directory structure ( which is not too di= fferent from the current, but - still will give the developers a lot more c= omfort as per your complain :-) ).
pgadmin/
- database_objects/
  - server/
    - __init__.py
    - create.py
    - get.py
    - sql.py
    - update.py
    - static/
      - img/
        - server.svg
        - server_bad.svg
      - javascripts/
        - server.js
        - ui_schema.js
  - database/
      - templates
        ...
    ...
  + schema/
  ...
  - tests/
    - api/
      ...
    - gui/
      ...
    - karma/
      ...
- browser/
  + pgagents/
  - server_groups/
    - servers/
      - databases/
        - __init__.py
        - node.py
        - schemas
          ...
        ...
      ...
    ...
  + tests/
- tools/
  + sqleditor/
  + dataviewer/
  + debugger/
- misc/
  + sql/
  + statistics/
  ...

NOTE:
We also need to think about the facts that.
Thes= e changes may lead to a lot of night mare packagers to make changes in the = installers in upgrade mode.

Also - when I say plug= gability/extendability, we should be able to create plugins on top of pgAdm= in 4.
Just take an example of this feature (Geospatial Query Viewer).

I think - it is best implemented as an plugin, as no= t every pgAdmin user will benificiary.
We need ability to load th= e modules as pluggable module same as we used to have before we introduced = the webpack to bundle everything as modules.
We also need to star= t thinking about it.

-- Thanks, Ashesh

Around minute 7 of this video Uncle = Bob shows an application written
in rails to talk about architecture. It= is a long KeyNote if you are curious I would advise you to see the full vi= deo.
His approach to architecture of the application is pretty interesti= ng.

=C2=A0


--00000000000093e58a056e5b5114--