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 1fSK5G-0006VN-4w for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jun 2018 10:29:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fSK5D-0006PK-GJ for pgadmin-hackers@arkaria.postgresql.org; Mon, 11 Jun 2018 10:29:55 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fSK5D-0006PA-6r for pgadmin-hackers@lists.postgresql.org; Mon, 11 Jun 2018 10:29:55 +0000 Received: from mail-ot0-x242.google.com ([2607:f8b0:4003:c0f::242]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fSK53-0007Ub-QW for pgadmin-hackers@postgresql.org; Mon, 11 Jun 2018 10:29:54 +0000 Received: by mail-ot0-x242.google.com with SMTP id c15-v6so13312977otl.3 for ; Mon, 11 Jun 2018 03:29:45 -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=IvOHRg5QF69Hm3dpcGC/ZH0CCnyt3NQf6xPBajs34ZM=; b=ds0nLzNwqomGqOZskcwoIQh7c6P0RmJQItmA6dyllT/8yJ0YOe+teNcgG+j5dAZXY5 8NT7oP4RApBFjemC+Z9ZsvznMNOtAesXS5xEXqT27xIC2jU0GQ4DmRZQxr8l4TdzfXUe yPSfmibMxfe+h2M3+3IgyNw3ozVvsnf4QuTQynMsP7Y7N+UhKOe5ZEJkzIgkFeo0gHIl +YEpdMjass9z0FS4vlS8h4eo/aJg8QXs7RGgnxOPrbjkxTiwkKgxOboctXrNKGG0CGgX Nt6Zcy2PSSEuROSpH8RZXYb0bAk5I2kEeBz7ftvw2TaiiNhobzgZLPbdRpvLYWFg8Hc5 zjvw== 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=IvOHRg5QF69Hm3dpcGC/ZH0CCnyt3NQf6xPBajs34ZM=; b=Vm/QhYhe6eQ/rSlgPqDEUqlVej6xCbh9WEiHz3SRmdqbsARgEbyXXeEg0JKoIPYfPz LPKYUqIz9X4A0MiEZYTq3rT1eXnq59dt92IB/ury2l6uihxJxSOvAguDdaA11Sqv0/Zm Xv1H9y82gK75uFUhL2dzpq0QRRBZl2ya+3vi+KHjSLciOlV3zDpvaEq1TC6SwNwDobiC 0NFM8UeZxdTGUczlDDppMv7nmf72/jEUrGa95SHYTcdaYTVb8ouM12GPVWUojSUo9Xxl K9Up6uRUXz9nG/vXZb1xTekCvb1Z5dn0xaoRMkuud5mn5DQB4lCu3qyQSWI7twjq/Hzy Z89g== X-Gm-Message-State: APt69E1yKmttfnXD4TJveVfqg26yJRZgvumk0BRghQ1Cicqu1UZfcfFZ rsOidK+70h+SJtnGP55xphoWMmTR2Pm9Fp+2s3dFLEsC X-Google-Smtp-Source: ADUXVKIgCqfb2cYPibfE5CZCQ6wiN2laPQoZiOzeBbQC9XOvp+h4k76HTOPIqTZbuvy2Dk/pCrYhdwqa5bwtnQj5rMU= X-Received: by 2002:a9d:49a8:: with SMTP id g40-v6mr10283620otf.223.1528712983247; Mon, 11 Jun 2018 03:29:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7a54:0:0:0:0:0 with HTTP; Mon, 11 Jun 2018 03:29:22 -0700 (PDT) In-Reply-To: References: From: Ashesh Vashi Date: Mon, 11 Jun 2018 15:59:22 +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="000000000000548d02056e5b3a09" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000548d02056e5b3a09 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 more > or less summarize the answers we care about > the location of the files, because we want our application to communicate > 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 th= e > 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 go > 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 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 app= ealing. > 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 is more appealing to me than the above one. The python package 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. 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 th= e > 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 more 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 in 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 to 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. > --000000000000548d02056e5b3a09 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Team,

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

...

3. Start the dis= cussion 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 on how d= o you see the application, and its expectations.
That question le= ads me to another question "What do we want from pgAdmin 4?"

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'.)
But - only under 'browser' (You can also call it object browser/= tree), it is driven by the database object relation model.
And, e= ach module maintains the parent-child relationship.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

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 - i= t gives me the idea what's the structure of the database objection rela= tionship.

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 abo= ut to touch the limit of maximum file system path.)

So - there is a scope for improvement there, we can leave without the obj= ect relations (but - limited to the object browser I think).
=C2= =A0

If= we open pgAdmin we know which nodes to click in order to get to tables. Bu= t for development
every time that you are looking for a specific functio= nality you need to run the application, navigate the menu so that
you kn= ow where you can find the code. This doesn=E2=80=99t sound very appealing.<= /p>

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 structure. I= t is more appealing to me than the above one.
The python package = contains the backend code, and static contains all your frontend.

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

This would saves us time because all the information th= at we need is what are we working 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 structur= e in application.
There are many reasons - why we need namespace = in C++, same applies here.

Let me start from the q= uestion "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 + Rever= sed 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 o= f 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 agr= ee, there is no boundry (or, very thin) between data & presentation at = the moment.
We can start from there.

I c= an think of the following directory structure ( which is not too different = from the current, but - still will give the developers a lot more comfort a= s 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.

=
I think - it is best implemented as an plugin, as not every pgAdmin us= er will benificiary.
We need ability to load the modules as plugg= able module same as we used to have before we introduced the webpack to bun= dle everything as modules.
We also need to start thinking about i= t.

-- 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

--000000000000548d02056e5b3a09--