- 
                Notifications
    You must be signed in to change notification settings 
- Fork 24
          Validate block database save/export operations with DataBlockResponse model
          #1311
        
          New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| 
  datalab 
   | ||||||||||||||||||||||||||||
| Project | datalab | 
| Branch Review | ml-evs/improve-block-test | 
| Run status |  | 
| Run duration | 08m 01s | 
| Commit |  | 
| Committer | Matthew Evans | 
| View all properties for this run ↗︎ | |
| Test results | |
|---|---|
|  | 0 | 
|  | 0 | 
|  | 0 | 
|  | 0 | 
|  | 336 | 
| View all changes introduced in this branch ↗︎ | |
d9f3b67    to
    55683e4      
    Compare
  
    | Codecov Report❌ Patch coverage is  
 Additional details and impacted files@@            Coverage Diff             @@
##             main    #1311      +/-   ##
==========================================
+ Coverage   78.90%   79.82%   +0.91%     
==========================================
  Files          68       69       +1     
  Lines        4679     4674       -5     
==========================================
+ Hits         3692     3731      +39     
+ Misses        987      943      -44     
 🚀 New features to boost your workflow:
 | 
55683e4    to
    399ae9d      
    Compare
  
    DataBlockResponse model
      7c77647    to
    8fd6785      
    Compare
  
    b7a8008    to
    2d68baf      
    Compare
  
    | This is the first of several scary technical debt resolving PRs, with this one changing how we save block data -- I've tried to test the current behaviour extensively so that we know when we are breaking it, but will need several follow-ups to refine it. Next up, trying to get pydantic v2 in... this PR started as an off-shoot for that to just robustify some of the tests! | 
| As our premier chat block user @jdbocarsly, I wonder if you just want to try out the refactored chat block locally after I merge this? I've significantly refactored it and added a lot of extra validation, plus a testing mode that uses Langchain's  | 
23a0ffe    to
    ee9278c      
    Compare
  
    ed4cc63    to
    10b4953      
    Compare
  
    10b4953    to
    3500700      
    Compare
  
    - Do not mutate block state when saving to db - Make sure block db update happens twice: once after receiving partial UI state, and once after block run
3500700    to
    8f0bb79      
    Compare
  
    - Nest XRD peak data under processed_data key - Add some verbose tests for block life cycle - Add metadata to block model - Remove defunct code for from_db, dereference_files and load_blocks - Strip potentially heavy ignored keys out of item save from app and API - Add metadata field for blocks - Use strings for file ID keys in nested block fields - Reintroduce uv-vis test - Fix issue where bokeh plot disappears after save
8f0bb79    to
    c714e70      
    Compare
  
    
This PR initially just updated the "all blocks" test to separate out each block and make sure that they were all doing something sensible. However, I realised that without the app to pass block data back in
update-blockcalls, some of the block results was not being saved in the database. This PR fixes that by explicitly calling_save_to_dbafter every block creation call, making thesave_to_dboption somewhat defunct.Following the principle of least suprise, I think the previous undocumented behaviour (i.e., being able to essentially see a block in an unsaved state) was not expected, so the only side effect here should be improved persistence.
In order to properly implement this, block operations now go through the new
DataBlockResponsemodel introduced in #1310, which we can refine over time. I've refactored the NMR, XRD and ChatBlock to extend and use this model directly. No other blocks should be affected, as of yet, as the model still allows extra keys to be passed through transparently. A future PR will have to try restrict this and refactor all blocks to store data in the correct places whilst maintaining backwards compat.