HUE-1844 [beeswax] Load back from History page

Review Request #3997 — Created Jan. 8, 2014 and submitted

abec
old-hue-rw
HUE-1844
hue
enricoberti, romain
commit 8d6cf8011978f29179c2bde11efbc53849b4e0c1
Author: Abraham Elmahrek <abraham@elmahrek.com>
Date:   Wed Jan 8 17:41:44 2014 -0800

    HUE-1844 [beeswax] Load back from History page
    
    Made the execute_query page automatically fetch results
    if 'query_id' in GET request.
    Changed APIs to use 'design' instead of 'query' for
    SavedQuery and/or design objects. 'query' is used for
    QueryHistory now.
    Fixed empty results page display.

:100644 100644 bf7b3c8... 674742b... M	apps/beeswax/src/beeswax/api.py
:100644 100644 14a19fe... 5d29753... M	apps/beeswax/src/beeswax/templates/execute.mako
:100644 100644 b289f97... 476b041... M	apps/beeswax/src/beeswax/templates/list_history.mako
:100644 100644 70661e6... 695f505... M	apps/beeswax/src/beeswax/test_base.py
:100644 100644 e9fb62b... 07524c2... M	apps/beeswax/src/beeswax/tests.py
:100644 100644 e9037d9... 35f13ac... M	apps/beeswax/src/beeswax/urls.py
:100644 100644 b5bc44a... 9af77b7... M	apps/beeswax/src/beeswax/views.py
:100644 100644 9ca348b... 34f4302... M	apps/beeswax/static/js/beeswax.vm.js
test all + manual. test all is still failing, but no new failures added.
Tested multiquery and history page.
  • 1
  • 0
  • 20
  • 3
  • 24
Description From Last Updated
will see if we need it back later (or an equivalent) romain romain
abec
romain
  1. If the query is still running, does it work? (history page is more a 'Dashboard Page')
    
    If we refresh the editor page, do we load it back where we are too? (could be a separate jira)
    1. If the query is running it does not work. I've noticed it just returns an empty result set now... maybe we should add the error message it sends back as well... will update.
      
      The state is lost when we reload the page. I've noticed this to be true in general though and multiquery statements do not work. Maybe a separate jira to work around this?
    2. This jira could be slit in two:
      
      1. load a design
      2. load a query history
      
      which are both available from the history page.
      
      refreshing the page is similar to #2. #1 is already working.
      
      reloading a running multi query page might not work, but this should be fine for now
      
      
  2. what is the logic? 
    (anyway to have it a bit clearer than calling twice a function)
    1. I'll add a small comment. Basically, if a design ID is provided, then the viewModel will not be ready until it has fetched the design and databases. Otherwise, it is ready after it has fetched the databases.
    2. How about something cleaner as a ko observable in the model?
    3. It has an undesireable effect. We basically want to check these things on start (never again). 
  3. will see if we need it back later (or an equivalent)
    1. My understanding is that this contains a design ID and a type or a database and table name. Lets do it in a separate Jira. I'm not entirely sure what this would be used for. When loading back history information, the design ID and query history ID should be sufficient?
  4. apps/beeswax/static/js/beeswax.vm.js (Diff revision 2)
     
     
    design_id exists? 
    1. Nope. Likely explains enrico's comments below 
  5. 
      
enricoberti
  1. Two things I found while testing the branch:
    - in case of an empty result the .empty-wrapper class is set to the element but there's no such a class for beeswax. Can you please put this code on hue3.css 
    
    .empty-wrapper {
        margin-top: 50px;
        color: #BBB;
        line-height: 60px;
      }
    
      .empty-wrapper i {
        font-size: 148px;
      }
    
    and get rid of all the other declarations of it? (fb/display.mako, rdbms/execute.mako and spark/editor.mako). That'd be great, thanks!
    
    - when I click on results the query editor is not prefilled with the query you are showing the results of. And the query tab neither. I think we should hide the Log tab too!
    1. Awesome points Enrico. I'll see what I can do about the empty wrapper mess and the query editor not prefilling. The problem I'm facing is the difference between a design and a query history object. The design is really the entity that stores the query information, and the query history object contains a design typically. If the query history object is missing a design (for what ever reason that may be) then this won't work properly. Maybe Romains comment on the design_id will fix this.
    2. A query_history always have design. In the past auto queries like a create or drop table from the metastore app used to not have one but this is changed.
      
      This is like the Spark app, we need to be able to load:
       1. a design, and it fills up the editor with the SQL, the selected DB...
       2. a query history, it fills up the design info above but also the logs, current status and the result if it is already finished
      
      #1 is like clicking on the query name of a saved query in the history page
      #2 is like clicking on the result link of a query in the history page
  2. 
      
abec
romain
  1. If we want to load back a query history, isn't a better way to do?
    
    e.g. we have a query_history id
     - load design from design
     - check status of query
      --> this will take care of the case the query is still running or finished and so show its result?
  2. apps/beeswax/src/beeswax/templates/execute.mako (Diff revision 2)
     
     
     
     
     
     
     
     
     
     
    it seems not very clear, cf above comment
  3. 
      
abec
romain
  1. So this looks way better!
    
    Except one little thing, I just see some naming convention problems. I think we should stay with the history names:
    
    design
    query_history
    
    It is a bit tedious bu will simplify a lot for the long term.
    
    Notice that design is actually a SavedQuery but it is fine to keep it as is.
  2. apps/beeswax/src/beeswax/api.py (Diff revisions 2 - 4)
     
     
    query_history_to_dict
  3. design can contain multi statements and is never running, so `query_history` should be better.
    
  4. we don't need 
    viewModel.design.history.id() > 0
    
    as it implies a design.id() already normally?
  5. the name makes sense
  6. execute_design
  7. watch_query_history?
  8. apps/beeswax/src/beeswax/views.py (Diff revisions 2 - 4)
     
     
    we should probably stick to 'query_history' as it is already super confusing with query, design, query history, saved query, query string etc...
    
  9. apps/beeswax/static/js/beeswax.vm.js (Diff revisions 2 - 4)
     
     
     
     
    could we build the urls in the fetch_query_history()?
  10. apps/beeswax/static/js/beeswax.vm.js (Diff revisions 2 - 4)
     
     
    good name
  11. apps/beeswax/static/js/beeswax.vm.js (Diff revisions 2 - 4)
     
     
    data.id ?
  12. apps/beeswax/static/js/beeswax.vm.js (Diff revisions 2 - 4)
     
     
    I think it is data.message now
  13. execute_design if we keep the logic?
  14. execute_design
  15. 
      
abec
romain
  1. Onwards!
    
    Will do a round of testing after
  2. apps/beeswax/src/beeswax/api.py (Diff revisions 3 - 5)
     
     
    response['query_history'] + update VM?
  3. so no need?
    1. Still need. That code mirror update is required whenever fetching designs.
  4. apps/beeswax/static/js/beeswax.vm.js (Diff revisions 3 - 5)
     
     
     
    we can get the urls from the history json now!
  5. apps/rdbms/src/rdbms/urls.py (Diff revision 5)
     
     
    query_history_id=
  6. apps/rdbms/src/rdbms/views.py (Diff revision 5)
     
     
    query_history_id=
  7. apps/spark/src/spark/urls.py (Diff revision 5)
     
     
    query_history_id=
  8. apps/spark/src/spark/views.py (Diff revision 5)
     
     
    query_history_id=
  9. 
      
abec
Review request changed

Status: Closed (submitted)

Loading...