embedded table: use DOMAIN to look up the resource fields #47
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Author
|
The unit-test failure is fixed by this pull request: #48 |
goneri
added a commit
to goneri/eve
that referenced
this pull request
Jun 12, 2015
embedded_fields may point on a field that come from another embedded document. For example, ['a.b.c', 'a.b', 'a'] The strategy is to sort out the different embedded_fields depending on their number of '.'. This way, the ones with the greatest depth level come last. Combined with pyeve/eve-sqlalchemy#47 it's now possible to do include multi-level embedded resource with Eve-SQLAlchemy.
goneri
force-pushed
the
embedded_with_DOMAIN
branch
3 times, most recently
from
dff7ba6 to
c38ac94
Compare
This patch resolve two issues: - it's now possible to have a resource field that is a relation to another relation, even if the name doesn't match. For example, product_stable and product_devel are two one-to-one field with a relationship to product - when we associate a foreign resource, we let eve.utils.embedded_document() decide what field should be import in the embedded resource. Previously, all the fields of the embedded resource were imported, with the thread of potential endless loops. For example, a any-to-one relation called `foo` with an associate to `bar` that we pull with embedded. `bar` has got a `foo_collection` with a link to `foo`. Previously, the `foo_collection` filed was automatically added in the list of field of `bar`. This was enough to create a resource loop in `lookup_foreign_resource`. - eve.utils.embedded_document() was confused because it was try to resolve itself embedded resource that were already pulled by eve_sqlalchemy.utils.sqla_object_to_dict(). Because of that, all the embedd resources were prefixed with a ID_FIELD in the final JSON. We now only retrieve the ID_FIELD value, as expected by embedded_document() - the patch, with https://github.com/nicolaiarocci/eve/pull/656 will allow the use of sub-embedded document
goneri
force-pushed
the
embedded_with_DOMAIN
branch
from
c38ac94 to
576979b
Compare
amleczko
added a commit
that referenced
this pull request
Jun 17, 2015
embedded table: use DOMAIN to look up the resource fields
goneri
added a commit
to goneri/eve
that referenced
this pull request
Jun 24, 2015
embedded_fields may point on a field that come from another embedded document. For example, ['a.b.c', 'a.b', 'a'] The strategy is to sort out the different embedded_fields depending on their number of '.'. This way, the ones with the greatest depth level come last. Combined with pyeve/eve-sqlalchemy#47 it's now possible to do include multi-level embedded resource with Eve-SQLAlchemy.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This patch resolve two issues:
another relation, even if the name doesn't match. For example,
product_stable and product_devel are two one-to-one field with a
relationship to product
eve.utils.embedded_document() decide what field should be import in
the embedded resource. Previously, all the fields of the embedded
resource were imported, with the thread of potential endless loops.
For example, a any-to-one relation called
foowith an associate tobarthat we pull with embedded.barhas got afoo_collectionwith a link tofoo. Previously, thefoo_collectionfiled was automatically added in the list of field ofbar.This was enough to create a resource loop in
lookup_foreign_resource.resolve itself embedded resource that were already pulled by
eve_sqlalchemy.utils.sqla_object_to_dict(). Because of that, all the
embedd resources were prefixed with a ID_FIELD in the final JSON.
We now only retrieve the ID_FIELD value, as expected by
embedded_document()
the use of sub-embedded document