-
Notifications
You must be signed in to change notification settings - Fork 266
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
Support # ended service paths in registrations #3078
Comments
The problem here is that no context provider can say all entities E with service path /a/# are mine. |
Another question here ... If recursive service paths are to be allowed, then a vector of service paths also should be allowed, right? |
One more thing, assuming we implement If more than one registration (of different context providers) matches an update/query, what should the broker do?
Example of registrations that could give more than one match: CP1 registers EntityId: 'E', EntityType: 'T', Service Path: '/#' CP2 is "stronger" ... Another option would be to check old registrations and if an overlap is detected, to refuse the registration. In my opinion, the best option is to not allow '#' in Service Path of registrations ... |
So, the discussion is not about if Just to be sure of what we are talking here :) |
Yes, first I believe we need to decide whether to allow recursive service paths or not. This decision defines the default value, / or /# If we decide to allow recursive service paths, then we need to decide how to tackle the problems that recursive service paths add. And also, should we allow a vector of service paths? |
In fact, they are independent issues. I mean, the problem of having two possible CPrs candidate for the same entity-attribute can happen even if these CPrs are defined using the same service path. In the past, we were dicussing about it in the original implementation of CPrs, even were dicussing as part of the "advance CPr functionality" that CB would be smart enough to cope with that situation (e.g. using the second CPr as backup of the first if the forwarded request fail or using some scoring algorithm to pick the best CPr). I don't remember exactly, but I think that for the "basic CPr functionality" mongoBackend returns the list of the possible CPr and the service routine pick some of them without any special criteria. And by the moment that is ok. On the other hand, the case of having the same CPr covering several service paths (even all the service paths) is a common use case. I don't see any reason to precluding it, specially if currently we are working that way in NGSIv1 registrations (to be checked). |
Tested with
It doesn't work. First, due to servicePathCheck() check in postRegisterContext(), which doesn't allow using |
Thus, my conclusions in this issue are:
|
Done in PR #3092. This PR would be rolled back if this issue is at the end implemented. |
Are there any plans on implementing this kind of behavior in the future? For me this seems like a common usecase. |
As far as I know, there aren't plans in the short future to address this. However, the issues discussion above contains useful information (code hints, functional test to be used to assure the functionality, etc.) so if somebody volunteers to implement this, we would be happy to review the PR and eventually merge the contribution :) |
Hey, thanks for your reply. I might take a look into the issue, but may not have the time to do so, will see. I understand the problem with diverging data when only updating the closest match in context providers. However, this can also happen with the current implementation, right? If an entity is already present within orion, a context provider will not receive the request anymore, hence possibly creating a different state on the provider versus the registered provider. |
I think the discussion was already solved and the conclusions posted in this specific comment: #3078 (comment), remarking:
So the same behaviour we have now (whatever it is :), I mean pick the first one, a random one, etc.) should be applied to a new scenario implementing also wildcards. |
From https://fiware-orion.readthedocs.io/en/master/user/service_path/index.html
Under that ligth, query associated be as wider as possible in the default case, thus
/#
is the one to use.We have deteced a part of places in the NGSIv1 registration logic where this doesn't occur. Check for FIXME marks with this issue number along the code
It should be fixed.
EDIT: check also
The text was updated successfully, but these errors were encountered: