That is what it seems
On Wed, Nov 22, 2017 at 10:14 AM, Ivan Kudryavtsev wrote:
> So, basically I changed it to
>
> sb.and("resourceUuid", sb.entity().getResourceUuid(), SearchCriteria.Op.IN
> );
> sb.and("resourceType", sb.entity().getResourceType(),
> SearchCriteria.Op.EQ);
>
>
> And launched
So, basically I changed it to
sb.and("resourceUuid", sb.entity().getResourceUuid(), SearchCriteria.Op.IN);
sb.and("resourceType", sb.entity().getResourceType(), SearchCriteria.Op.EQ);
And launched marvin tests. I suppose resourceId filtering is completely
wrong here.
22 нояб. 2017 г. 7:12 ПП п
Then, I believe we can remove that filter in the search criteria as you
suggested and also remove the line 308.
On Wed, Nov 22, 2017 at 10:12 AM, Ivan Kudryavtsev wrote:
> Yes, you are right, but there are no other ids in the query, and rarely
> (like in my case) it leads to wrong results.
>
> 2
Yes, you are right, but there are no other ids in the query, and rarely
(like in my case) it leads to wrong results.
22 нояб. 2017 г. 7:07 ПП пользователь "Rafael Weingärtner" <
rafaelweingart...@gmail.com> написал:
> The problem seems to be related to line 308 at
> com.cloud.tags.TaggedResourceM
I did not understand what you said. Are you talking about the data used in
the SQL filters?
On Wed, Nov 22, 2017 at 10:10 AM, Ivan Kudryavtsev wrote:
> So, I don't understand. As you can see there is no longs in sql dump. Just
> uuids. I run actual delete tags query against simulator and it lead
So, I don't understand. As you can see there is no longs in sql dump. Just
uuids. I run actual delete tags query against simulator and it leads to
this sql search which filters wrong data. As I see, query is incorrect.
22 нояб. 2017 г. 7:03 ПП пользователь "Rafael Weingärtner" <
rafaelweingart...@
The problem seems to be related to line 308 at
com.cloud.tags.TaggedResourceManagerImpl.deleteTags(List,
ResourceObjectType, Map).
It is being sent a list of resourceUUID as the filter for resourceId
On Wed, Nov 22, 2017 at 10:03 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:
> The
The resourceId is not a real DB ID. It is the UUID converted to Long :(
This table has four "ID" like fields, ID, UUID, resourceID, and
resourceUUID.
On Wed, Nov 22, 2017 at 10:00 AM, Ivan Kudryavtsev wrote:
> Hi, I just enabled log all queries and copied actual query which I have
> shown in
Hi, I just enabled log all queries and copied actual query which I have
shown in the first mail. Also, I don't understand why the search should
look over inner ids... Is it a case when user can pass real db ids to an
api call?
22 нояб. 2017 г. 6:55 ПП пользователь "Rafael Weingärtner" <
rafaelwein
Yes, this I understood ;)
However, I do not understand how the SQL that is being generated has this
clause: " resource_tags.resource_id='2a4264fb-9f63-4d4f-9465-c1bc5440ea60'".
The resourceId field in the entity is a long. So, even though that long
represents a String, in the final SQL that is gen
Take a look here:
SELECT resource_tags.id, resource_tags.uuid, resource_tags.key,
resource_tags.value, resource_tags.domain_id, resource_tags.account_id,
resource_tags.resource_id, resource_tags.resource_uuid,
resource_tags.resource_type, resource_tags.customer FROM resource_tags
WHERE ( resource
Ah, ok now it makes sense the "IN", I thought you were only talking about
single values.
I do not think that the UUID (resource UUID) is the representation of ID
value in Hexadecimal, if it is we could simply get rid of one of them. I
really dislike these search criteria...I am not seeing what y
I mean that it's like SQL injection. API call expects UUID for resourceID,
but in code that API value is checked against resourceID which is integer
and internal to DB and against resourceUuid which is known for API... This
looks weird even without keeping in mind it grabs extra irrelevant results
Hi, Rafael, 'IN" because API call assumes that several resourceIds can be
provided, so IN solves it, EQ doesn't.
But despite semantics ID/UUID you see that ID is integer and UUID is string
and that comparison does fault positive results, next when object access
for caller is checked exception occu
Are ID and UUID set with the same values in that entity? If not, the
criteria seem correct. I mean, it is trying to filter for an ID if it
exists or by UUID if it exists in the entity that is passed as an example.
What I do not understand is that they are using “SearchCriteria.Op.IN”, but
in my opi
Hi, I found interesting behaviour with tags:
mysql> SELECT resource_tags.id, resource_tags.uuid, resource_tags.key,
resource_tags.value, resource_tags.domain_id, resource_tags.account_id,
resource_tags.resource_id, resource_tags.resource_uuid,
resource_tags.resource_type, resource_tags.customer FR
16 matches
Mail list logo
