[
https://issues.jboss.org/browse/WFCORE-2042?page=com.atlassian.jira.plugi...
]
Michal Petrov commented on WFCORE-2042:
---------------------------------------
(I "stole" the name from SQL, I don't think it's confusing and it
doesn't have to be called that)
I feel like changing how "where" works makes the operation behave significantly
differently for different queries. As it is now
{code}
ADDRESS:query(select=[a], where={b=c})
{code}
performs read-resource on ADDRESS and if the condition is met removes all attributes from
the result except for "a". So first "where" filters out the resource
as a whole and then "select" filters its attributes (and they work independently
of each other). Changing "where" to look into nested attributes would create a
dependency between the two because select would also have to filter out the children that
don't meet the "where" condition (in cases where the attribute is a list).
I'm proposing simply shifting the scope of the operation from the parent resource to
its attribute (that otherwise isn't addressable).
Improve query operation for nested child resources
--------------------------------------------------
Key: WFCORE-2042
URL:
https://issues.jboss.org/browse/WFCORE-2042
Project: WildFly Core
Issue Type: Feature Request
Components: Domain Management
Reporter: Lin Gao
This is another similar RFE as WFCORE-2041.
It would be good if the 'query()' operation can filter the resources by
specifying value of attributes which are +inside of nested child resources(not only by
the first level of child resource)+, so that, for example, the following command can work
well as expected:
{code:}
[standalone@localhost:9990 /] /subsystem=security:query(select=[security-domain],
where={security-domain.authentication.login-modules.code=RealmDirect})
{
"outcome" => "success",
"result" => undefined
}
// here the expected output are the security-domain resources which have the
loging-module RealmDirect defined.
{code}
The {{security-domain.authentication.login-modules.code}} in 'where' parameter is
proposed attribute name in enhanced syntax, other options maybe possible.
The different requirements between this WFCORE-2042 and WFCORE-2041 are:
* WFCORE-2041 focus on complex attributes in one management resource
* WFCORE-2042 focus on nested management resources with or without complex attributes
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)