Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
little http_resource_services bug
Stumbled over a bug in http_resource_services in GetColumnValues
The Delete statement screws up the results because you're within a loop retrieving columnname from the ColumnNames array.
Deleting here means you skip one element you're looking for because ColumnNames has been reduced by one plus the results are also out of sync, meaning the values returned, whilst correct, are not necessarily aligned with the correct name.
Deleting the columnnames here doesn't delete it from the response.
I can see from the commentary further above that you're not expecting anyone to trip over this so perhaps it's poor design on my part
but ....
I might decide I want to do that anyway.
If KeyPart EQ 0 then
ColumnNames = Delete(ColumnNames, ColumnCnt, 0, 0)
end else
ColumnValues := ColumnValue : @FM
end
The Delete statement screws up the results because you're within a loop retrieving columnname from the ColumnNames array.
Deleting here means you skip one element you're looking for because ColumnNames has been reduced by one plus the results are also out of sync, meaning the values returned, whilst correct, are not necessarily aligned with the correct name.
Deleting the columnnames here doesn't delete it from the response.
I can see from the commentary further above that you're not expecting anyone to trip over this so perhaps it's poor design on my part
If Len(KeyPart) then
// This is a Key ID column. If KeyPart is 0 then this represents the entire
// Key ID, which is not normally returned since the Item ID is already known
// and will appear in the URL. If this is a multipart Key ID then KeyPart
// will be an integer. This value should be returned since it likely is a
// significant part of the resource.
If KeyPart EQ 0 then
ColumnValue = @ID
but ....
I might decide I want to do that anyway.
Comments
Is that happening or you assuming it will.
Appears to be OK here (I see what you mean in the code, though)
I have to agree with your assessment about this. Honestly, as I look at the code I can tell this was never tested well. The reason for that is because I practiced what I preached: don't put a Key ID as one of the column names to be returned.
So I think I was trying to be extra clever and intended to remove the redundant Key ID automatically. However, as you pointed out, there are two flaws with the code: 1.) It is deleting from the active array while the array is being processed from the beginning to the end, thus it forces the next item in the array to get skipped, and 2.) it does not actually do anything to the column names array, just the column values, so they are out of sync.
If I wanted to fix issue #1, I would reverse the order and start at the end and work my way to the beginning. However, #2 is just too much work to try and enforce a rule that perhaps should be left to the developer. So, I'll remove the relevant code on my end and schedule this for the next update.
As a glimpse into the future: I am planning and adding support for MV Groups in HTTP_Resource_Services. So, when you use the GetDatabaseItem/s services, all associated multivalues will be become arrays under a sub-object labelled after the MV Group name.
Yes it's happening though upon rereading my post I realise I just assumed everyone else knew what I was talking about because I mean, why wouldn't they, I've had my head in the code for an hour....
The issue only arises if the key is a single part key and you add it to the columnnames list to be returned. If you don't do this as per Don's recommendation, then you won't experience the issue. Furthermore, if you add the key as the last column, then it may still appear to work because it doesn't misalign anything else but simply returns "null" as the key.
Don,
I suspected it was a practice what you preach oversight and was just going to fix it up myself but then thought better to bring it to your attention in case there was something cleverer you wanted to do with it.
As for your glimpse into the future, I think I understand what you're saying and look forward to it.
Among other things I was today trying to figure out how I create a response that has objects within objects where I want them. I suspect we may be talking about the same thing. Whilst I may in many cases be referring to mv's it may not always be the case.
Take this screenshot for example.
Here 'address' is a four item object within one of the three 'customers' objects which in turn is an object within the primary object.
Is there a way in the current http_resource or http_json services world to achieve this kind of result?
Yes, what I am describing is as your screen shot is demonstrating.
However, the only way this can be handled automatically is if there is metadata that can be used. Thus, I can implement this in HTTP_Resource_Services because dictionary columns store the name of the MV Group.
What you want to do is something the dictionary column can't define for me so arbitrary groupings of non-multivalue columns is beyond the scope of a generic utility like HTTP_Resource_Services.
The same thing can be said about HTTP_JSON_Services. It can only be designed to build JSON objects that are relatively simple, or it will simply become too complex to call.
So, in case likes like what you are referring to (which I've had to deal with in my own projects), I've had to forego HTTP_Resource_Services and HTTP_JSON_Services and roll-out my own HAL+JSON respone in the web service routine. I usually start by copying the code from the SetHALItem service from HTTP_JSON_Services and then adapt for the representation of the resource I'm interested in.
Happy to do it that way. Just making sure I wasn't missing something already available.
I will put this in the upcoming 2.0.2 version of the product. However, I would be interested in having others test these changes. You will need to have dictionaries with MV Groups defined for this to work. If anybody is interested I can send you the source code as two attachments so you don't have to re-install the complete SRP HTTP Framework. These routines should work in harmony with older versions unless you customized these routines yourself.