public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ashesh Vashi <[email protected]>
To: Joao De Almeida Pereira <[email protected]>
Cc: Dave Page <[email protected]>
Cc: Anthony Emengo <[email protected]>
Cc: Khushboo Vashi <[email protected]>
Cc: Murtuza Zabuawala <[email protected]>
Cc: pgadmin-hackers <[email protected]>
Subject: Re: [pgadmin4][patch] Initial patch to decouple from ACI Tree
Date: Mon, 11 Jun 2018 16:05:52 +0530
Message-ID: <CAG7mmozbJ1rrCugh+csBE756uQ17_=irURwsLDv=HEhbeQ+_pA@mail.gmail.com> (raw)
In-Reply-To: <CAG7mmowGmtwfR+yBJ6d05N0pS+vEwTWC_ZoQ_RxZPf99T+sp8g@mail.gmail.com>
References: <CAE+jja=Gdd032H7tpoZD2C0m2R7SnTZpHX_oPx2K2zGbaaW9yg@mail.gmail.com>
<CAFOhELcrZsRkwV4beOC7UT_HYvi9Rk=HFJ355g8Bj4bqyzMLog@mail.gmail.com>
<CAE+jjaneGOR_R7QvYnZt=khumRsyhnrzFRhpMG5-Q+rR9guLzQ@mail.gmail.com>
<CAKKotZROcoO_rtrrJUTvpfgSh1w4ig1ogQrkDrKSQHuKEL7CdQ@mail.gmail.com>
<CAE+jjakEZtn0ct128Xd+es5xCZ5eZLwoNZw6X0ue7oFB+a83oQ@mail.gmail.com>
<CAFOhELe_t_QGBbcYYm3Zrfwf3z9674PY5sy2QS46wHDTf-8DHA@mail.gmail.com>
<CAE+jja=u+W+FNaWGVs1KPZm1eYA_F=7ktomSbmsxOo-cjuOdBw@mail.gmail.com>
<CAE+jja=TZzMXOq4+t=dA+LfTGkW66urB37Tt9sEJ_UjAiymbbQ@mail.gmail.com>
<CAE+jjamSM_pBLNmYLn6-hWMiQvToceV2iPuME-eH5c+tgaYf7A@mail.gmail.com>
<CA+OCxowN15jg_DV4o+R+OSczyGHHccnJ1sPXE_XukYugaTKyyw@mail.gmail.com>
<CA+OCxozTMcEDKZEu9YCOsSBSed23Ka8hHiO5s6VF76KopbipNQ@mail.gmail.com>
<CAG7mmowrM3b8cTY+zcCAcVma8CKWHwXSF3=BUDcSFLpjH=jQBg@mail.gmail.com>
<CAE+jjanjQ295x0DgffT8OARRv8fge5KOPJpMCnLWe+j0jdqGJQ@mail.gmail.com>
<CAG7mmoym9838PVKdDD=469Bsx6AFBV1ThMK_dyitUmG26147Qg@mail.gmail.com>
<CAG7mmoy=5W3scnPs-TVpcu49F7gZU2qySPaakwfEdcg6rg2RMQ@mail.gmail.com>
<CAG8BBZOAFgw6iDseWTSEUC+tiwc0zCoQyycXGFWbW6ueftCggA@mail.gmail.com>
<CAG7mmoyirqdDGZnXcz5odMBnsOYY83Dj6Uw8gV59OPTJSnaMAg@mail.gmail.com>
<CA+OCxoz3C+HRDzh05SKhMjSZPnHezf=F0eiNoo_HHqUtiJWPiQ@mail.gmail.com>
<CAG7mmoxjfZGA8Gp4HMByTAf6ZLZ7Oaj2yTUrgbOrpJ0H7OtQNQ@mail.gmail.com>
<CAE+jja=GFVqodrWJ+vzBYO4tzoZipKqdThKUqMOGyoZPtJc1+Q@mail.gmail.com>
<CAG7mmozE+8pneLOp8RokHZiav0kcM2Ts6NkHwrz2n31-Ykn_kA@mail.gmail.com>
<CA+OCxowNhQ7waRSPp5P--dFisLFkf+EEOwH+y0+t+ZT9dXLXTA@mail.gmail.com>
<CAE+jjamkYzDxjvSmdkU-1Gyys1FXtrXGr+d7=yrsAREmXsteOQ@mail.gmail.com>
<CAE+jja=vaQOE6XbJH34+N24CZY1DRdYz8wgkxxTx5KSaqw7pLQ@mail.gmail.com>
<CAG7mmowGmtwfR+yBJ6d05N0pS+vEwTWC_ZoQ_RxZPf99T+sp8g@mail.gmail.com>
On Mon, Jun 11, 2018 at 3:59 PM, Ashesh Vashi <[email protected]
> wrote:
> Hi Team,
>
> On Sat, May 5, 2018 at 3:31 AM, Joao De Almeida Pereira <
> [email protected]> 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
>> 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 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 *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’t sound very appealing.
>>
> 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
>> 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 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)
> <https://www.postgresql.org/message-id/[email protected]...;
> .
>
> 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
>> <https://www.youtube.com/watch?v=hALFGQNeEnU; 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.
>>
>
>
>
view thread (69+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: [pgadmin4][patch] Initial patch to decouple from ACI Tree
In-Reply-To: <CAG7mmozbJ1rrCugh+csBE756uQ17_=irURwsLDv=HEhbeQ+_pA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox