Thu, Jul 30
Wed, Jul 29
happy with how this turned out... thanks leor!
update, use snapshot id
Tue, Jul 28
- handle repository origin union, with grpc
If everyone's on board with this approach, we should also update the docs for materializers.
We may want to revisit this later, but for now abandoning in favor of simpler client-side checks / warnings
I think this is looking pretty good! nice work...
Fri, Jul 24
Thu, Jul 23
I think this looks good to me! +1 to the Preparable homage
- update web tests
remove example change
- make code pointer metadata generic
- extract RepositoryInformation component
- renamed python origin
- added instance query, hook for dagit executable path
Wed, Jul 22
- allow import error handling to bubble up into register call
Tue, Jul 21
- guard against import error
Mon, Jul 20
This is looking pretty good!!
- fix py27 requirements
- add explicit dev requirement, bury yield in tree for tests
Fri, Jul 17
yep, this looks good to me!
Thu, Jul 16
rename Materialization => AssetMaterialization, Asset Key => asset_key
Considered it, but it felt a little strange to me to be mutating the metadata entries like that.
- Fine with changing Materialization => Asset Materialization in the event type, but I don't feel that strongly about it and might be outside of the scope of this diff.
- I think the metadata key can be completely arbitrary... there's no reason why it should be asset_key vs Asset Key. Users can specify whatever labels they want in their metadata.
- For AssetMaterialization the asset key is the same as the label, but I was just considering relaxing that and adding an optional label parameter. At any rate, for legacy Materialization events, the two values are different, so they are not redundant in all cases.
This all looks great.
Code looks fine, but curious what the bug was....
- remove optionally
- add changelog; fix apidocs ref
- error messages
- update docs
Wed, Jul 15
good catch, sandyryza
rebase, switch to constructor flag
Yeah, this is interesting... Do we anticipate being able to add hooks for any arbitrary event type? The signature we have at the moment is generic enough to handle that.
Probably performance-wise this should be a generic Dagster checker instead of a finally-yield specific checker. and then we could just add specific warnings.
Tue, Jul 14
love to hear the story on this find
Mon, Jul 13
- remove default_to_storage_value default
Fri, Jul 10
I think _check_serdes_tuple_class_invariants is actually fine... it's checking the __new__ arguments against the underlying named tuple. None of those invariants should change, since we're still supporting the constructor both for persistable and the non-persistable...