Comments (7)
For the reference: https://github.com/Ocramius/GeneratedHydrator
from porter.
Something like this https://github.com/doctrine/DoctrineModule/blob/master/docs/hydrator.md ?
from porter.
DoctrineModule is not suitable because it is both Doctrine specific and Zend Framework specific. Porter requires a general purpose hydration solution.
As an aside, even for Doctrine and Zend Framework users, the hydrator provided by DoctrineModule is incomplete since it does not support embedded documents nor discriminators.
from porter.
i understand, it's just example about how this module can work
from porter.
Something like @Ocramius's GeneratedHydrator could be ideal. I haven't used it yet but it looks promising. If it is suitable we still need to decide whether to integrate it directly or create a hydrator interface such that it can be swapped out for something else if the user wishes.
from porter.
If someone wants to attempt hydrator integration, this can now be achieved easily by implementing the Porter 3 Transformer interface and can even be developed as a separate project. In this way we can have as many hydrator transformers as hydrator implementations thus allowing a developer to pick whichever implementation they prefer.
However, after deeper consideration, I now think hydration should not be integrated into Porter at all. Hydrators typically create objects by ignoring the constructor and mutators, forcing potentially invalid state into objects. This is fine when the state is guaranteed to be valid but data coming from a third party cannot usually meet such guarantees. Of course, if there is a hydrator that does invoke an object's constructor and calls its setter methods, this should be fine.
An alternative approach worth consideration is writing a validation transformer before the hydrator to ensure incoming data is valid. Such a transformer would not actually transform the data at all, but rather, simply read the incoming data and throw an exception if it is not compliant.
One final note about hydrators: the interface for Transformer
specifies it must return a RecordCollection
. Such a collection is defined as a collection of arrays, however a hydrator would violate this by emitting a collection of objects. In principle this is not a problem as long as you can guarantee the hydration transformer is the last in the queue; otherwise it would break all subsequent transformers that expect arrays.
from porter.
After further consideration I do not think it makes any sense to integrate hydration into Porter. This includes strategies whereby the constructor of the object is invoked like normal.
The first problem is Porter::import()
returns a RecordCollection
, which is an iterator of arrays, and similarly, Porter::importOne()
returns an array
. Having a hydration transformer at the end of the transformation queue violates this interface by returning an object. However, we could add separate methods for importing hydrated objects.
The second problem is that even if we have another method to import hydrated objects, the best interface we can design for that method is one that returns object
, so we still don't know what type of object the call will yield.
For these reasons it is better to leave hydration to the API wrapper class one typically writes to abstract Porter away from the caller. Hydration is therefore not a direct concern of Porter nor even of her plugins (i.e. transformers).
from porter.
Related Issues (20)
- CachingConnector::fetch should allow passing in the cache key HOT 1
- Durability is broken for subsequent generator iterations after the first HOT 2
- HttpConnectorTest intermittent CI failure HOT 1
- Type classes should be migrated to phptype organization HOT 1
- Retry delays are tied to the lifetime of an import specification HOT 1
- Drop PHP 5 support HOT 2
- Document FetchExceptionHandlers
- [BC-BREAK] scriptfusion/retry 1.1.2 HOT 2
- Rate Limiter HOT 2
- How I can get what went wrong at import process ? HOT 1
- Reconsider whether forcing resources to return arrays is correct
- Laravel and CachingConnector? HOT 2
- CachingConnector is a poor user experience HOT 1
- ConnectorOptions is a bad design
- SingleRecord interface
- ExponentialAsyncDelayRecoverableExceptionHandler not being cloned correctly
- Integrate async throttle
- Document multiple instances of same provider
- Document Symfony integration best practices HOT 1
- Dependency on psr/cache:^1 HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from porter.