HUE-1908 [beeswax] Database of a saved query is not loaded back when opening it

Review Request #4062 — Created Jan. 27, 2014 and submitted

abec
old-hue-rw
HUE-1908
hue
enricoberti, romain
commit a9ba2092e917ccd3321680617325f7410613f9bb
Author: Abraham Elmahrek <abraham@elmahrek.com>
Date:   Mon Jan 27 14:48:04 2014 -0800

    HUE-1908 [beeswax] Database of a saved query is not loaded back when opening it
    
    Need specific logic for different states: query history, design, and execute query.
    If query history or design, need to wait for databases and design/query to load.
    Otherwise, just need to wait for databases to load.

:100644 100644 1d2cd39... 285c530... M	apps/beeswax/src/beeswax/templates/execute.mako
:100644 100644 07dd2bf... cb54c16... M	apps/beeswax/static/js/beeswax.vm.js
Tested load query history, load design, and normal query. In normal query case, cache is dominant. In load query and load design, cache is dominant after designs have been loaded.
  • 1
  • 0
  • 0
  • 0
  • 1
Description From Last Updated
Can't it be reverted to 914-917 of before? Is the DB fetching triggering a change() on it? (trying to see ... romain romain
romain
  1. I would prefer to no add any new state management, it is already very complicated (spending 3hours on error popups for example..)
    
    How about adding 3 clear new methods in the vm and one main loadEditor that is called in the template:
    
    viewModel = new BeeswaxViewModel("${app_name}")
    % if queryHistory
      viewModel.loadqueryHistory(queryHistoryId)
    % elif design:
      viewModel.loadDesign(designId)
    % endif
    ....
    
    
    
    loadEditor() {
      // load DB there for example
    }
    
    loadDesign(id) {
      loadEditor()
      loadDesign(id)
    }
    
    loadQueryHistory(queryHistory) {
      loadDesign(queryHistory.designId)
      loadQueryHistory()
      ....
    }
    
    
    
  2. 
      
abec
romain
  1. better!
    
    Could we get ride of all the $(document).one() in this ticket, I think they complexify for no reason. We load only once everything
    1. Which $(document).one() are you referring to? There are several through out the execute.mako page. I think you mean the ones within the loadEditor, loadDesign, and loadQuery functions? If so, replace with callbacks?
  2. 
      
romain
  1. So I see:
    #1 with multiple callbacks, maybe the most elegant but also many more states..
    #2 with a sync pooling of the DB, then loading the design
    #3
    we load the design and add the DB to the list of DB if it is not there
    the fetch DB will update correctly the selected DB if needed
    
    I guess current version with below comment might be a compromise
    1. I'm actually less of a fan of callbacks. Events tend to be more extensible and about as difficult to follow as callbacks IMO. In these cases with the one-offs... call backs versus events is irrelevant though. Might be able to change to callbacks (not sure). Maybe the trick is to further linearize the events or to introduce functional, reactive programming methodologies to this code base. Wondering if we can use baconjs or something.
    2. I was just thinking that we could just load the DB in the backend or with a sync call and it would be simpler with the same result.
    3. synchronized API calls are costly I guess. What if HS2 goes down? This would freeze browser for sometime.
  2. apps/beeswax/src/beeswax/templates/execute.mako (Diff revision 2)
     
     
     
     
     
     
    Can't it be reverted to 914-917 of before?
    
    Is the DB fetching triggering a change() on it?
    (trying to see if we can remove the fetched.databases event)
    
    1. The change event will be called. It then overwrites the cache. So it needs to be moved around.
  3. 
      
romain
  1. Ok, let's go with this one!
  2. 
      
abec
Review request changed

Status: Closed (submitted)

Loading...