Environment layer #52
Conversation
The Environment layer does not keep its own mapping of custom object types. If we think it likely that users will want to maintain separate lists of custom object types between two or more Environments, we can add this later.
1) 'stix_data' is now optional; you can set up a MemorySink without needing a starting set of data. 2) Removed stix2-validator calls. The validator fails when called on our _STIXBase-derived classes because we store timestamps as datetime objects, while the validator expects strings. Also, this was the only datastore that used the validator, and we should be consistent across all of them. The validator can be added back in later.
Codecov Report
@@ Coverage Diff @@
## master #52 +/- ##
========================================
+ Coverage 95.27% 96% +0.72%
========================================
Files 53 53
Lines 4506 4626 +120
========================================
+ Hits 4293 4441 +148
+ Misses 213 185 -28
Continue to review full report at Codecov.
|
| return self.source.get(*args, **kwargs) | ||
| except AttributeError: | ||
| raise AttributeError('Environment has no data source to query') | ||
| get.__doc__ = DataStore.get.__doc__ |
There was a problem hiding this comment.
I feel like these should use the DataSource docstrings, but after taking a look at those, they could probably be cleaned up and reorganized between DataStore and DataSource. It's fine for now. I created #53 to address that.
|
My first impression is that keeping track of custom types should be an Environment function. A user could conceivably want different settings in different parts of your application, which is the purpose of the Environment class. If we decide that we want to enable custom types outside of an explicit environment (which I'm not sure we do), that means we need to keep an implicit environment for that. The core I'm fine with not running the validator for every DataSource/DataSink interaction. If it's needed, we can later add a boolean I'd love to hear others' opinions, especially if I'm missing any use cases. |
|
I agree that users will want different settings in different parts of their application. But specifically for custom types, my thinking was that the only time you would have a problem with registering them "globally" (like we do currently) is if you need 2 with the same name but different properties. In that case you would need to be able to register them to separate environments, but I assumed that is an unlikely occurrence. |
|
I was also thinking that you might want to allow custom types in some environments but not others. That does bring up the questions of how to register the same custom types in multiple environments, whether to still have a set of "global" custom types that apply to all environments, whether environments should allow nesting/inheritence, etc. It gets pretty complicated and IMO over-engineered pretty quick. I guess what I'm saying, though, is that which custom types are supported is an environment-specific setting, but I could be wrong. The fact that the |
Open questions:
Closes #37