chris-fox commented 3 years ago

Using this issue to track limitations in Enterprise Feature Service api that require updateDefinition requests after initial addToDefinition requests. This is to bring parity between ArcGIS Online and Enterprise and improve performance of Feature Service creation.

Works in initial addToDefinition request

Feature Service

[x] drawingInfo
[x] templates
[x] types

Single Source View

[x] drawingInfo
[x] templates
[x] types
[x] typeId
[x] viewDefinitionQuery
[x] Field overrides (Alias, Domain, Visibility)

Multi Source View

[x] drawingInfo
[x] sourceSchemaChangesAllowed

Additional Issues

[ ] Relationship ids are not being persisted #724
[ ] Unique indexes are not being added to layer

chris-fox commented 3 years ago

From my testing Enterprise team has resolved all of these for 10.9.1. I would like to test removing our Enterprise specific logic for creating services and views to see if we can simplify this logic between Online and Enterprise.

jmhauck commented 2 years ago

@chris-fox timeInfo is also being cached and updated later

jmhauck commented 2 years ago

@chris-fox also came across this one...portal will fail when initialExtent is defined but null

449

jmhauck commented 2 years ago

@chris-fox another section with some field work that mention and handle:

When deploying to portal we need to adjust the uniquie ID field up front (we lowercase it)
Portal will fail if the geometryField is null
Portal will fail if the sourceFields in the viewLayerDef contain fields that are not in the source service

chris-fox commented 2 years ago

@chris-fox another section with some field work that mention and handle:

When deploying to portal we need to adjust the uniquie ID field up front (we lowercase it)

Portal will fail if the geometryField is null

Portal will fail if the sourceFields in the viewLayerDef contain fields that are not in the source service

@chris-fox also came across this one...portal will fail when initialExtent is defined but null

449

@jmhauck, for the unique ID field, I am wondering if we need to worry about this anymore since we are not swapping this in the template with the work you did in the python code:

        "uniqueIdField": {
            "name": "[[OBJECTID||objectid]]",
            "isSystemMaintained": true
        },

For these ones can we make this the same logic for ArcGIS Online? I am assuming Online doesn't care either way and we can just have the same logic and we should be good.

jmhauck commented 2 years ago

@chris-fox should I expect the same results across windows and linux in terms of the fixes?

chris-fox commented 2 years ago

@jmhauck, yes you should

jmhauck commented 2 years ago

@chris-fox Single Source View with field visibility set to false in addToDef is true in the result

chris-fox commented 2 years ago

@chris-fox Single Source View with field visibility set to false in addToDef is true in the result

Thanks, I will follow-up. This was a specific scenario I asked them for.

jmhauck commented 2 years ago

@chris-fox we are also filtering capabilities for portal. We only keep ones if they are in this list: "Create", "Query", "Editing", "Update", "Delete", "Uploads", "Sync", "Extract".

jmhauck commented 2 years ago

@chris-fox also not seeing changes to domains in a view honored...they are always being set to match what the source has.

chris-fox commented 2 years ago

@chris-fox we are also filtering capabilities for portal. We only keep ones if they are in this list: "Create", "Query", "Editing", "Update", "Delete", "Uploads", "Sync", "Extract".

@jmhauck, yea I think we need to keep this logic for now.

chris-fox commented 2 years ago

@chris-fox also not seeing changes to domains in a view honored...they are always being set to match what the source has.

Hmm..I will check it out. I thought this was working for me when I used the same isViewOverride flag on the field as Online.

chris-fox commented 2 years ago

@jmhauck, so I reviewed the issue and the Enterprise team implemented this slightly different. They are expecting we pass the full field definitions including visibility and alias and domain overrides inside the adminLayerInfo of the layer. So for example:

{
    "layers": [{
        "adminLayerInfo": {
            "geometryField": {
                "name": "shape"
            },
            "viewLayerDefinition": {
                "sourceServiceName": "CPR",
                "sourceLayerId": 0,
                "sourceLayerFields": [{
                    "name": "objectid",
                    "source": "objectid",
                    "type": "esriFieldTypeOID",
                    "alias": "OBJECTID",
                    "sqlType": "sqlTypeOther",
                    "nullable": false,
                    "editable": false,
                    "visible": true,
                    "domain": null,
                    "defaultValue": null
                }, {
                    "name": "probid",
                    "source": "probid",
                    "type": "esriFieldTypeString",
                    "alias": "Problem ID",
                    "sqlType": "sqlTypeOther",
                    "length": 100,
                    "nullable": true,
                    "editable": true,
                    "visible": true,
                    "domain": null,
                    "defaultValue": null
                }

I tested ArcGIS Online, and it doesn't work with this definition alone. I then tested if I passed both the fields in the adminLayerInfo and a Fields array at the root of the layer definition and it worked in both Online and Enterprise. Attached is a sample json file I used to add a view layer that successfully updated the visible property on the userid field and the domain and alias on the probtype field. I am hoping we could use this approach consistently in Online and Enterprise.

addtoDefinition.zip

chris-fox commented 2 years ago

@jmhauck, I was deploying this solution today to enterprise, https://localdeployment.maps.arcgis.com/home/item.html?id=87402cd572f04923859b9202731d0feb and it was failing on template 'e5bea6f9e136423583f2379e8606aef8' during addToDefinition because the drawingInfo was being set to null.

{"error":{"code":500,"message":"JSONObject[\"drawingInfo\"] is not a JSONObject.","details":[]}}

However, when I check the original template in the solution item the drawingInfo is not null, not sure why this is happening, but wanted to add this test case to your testing.

I wanted to add there is another service in the solution that is failing, but appears to be because it is using a reserved word for a field name "length". I will work with the team on this.

jmhauck commented 2 years ago

@chris-fox it's failing on addToDef when a view field is marked as visible false but is used elsewhere in the addToDef such as a viewDefQuery or within the templates.

chris-fox commented 2 years ago

@jmhauck, and from this I am assuming the way we were doing it previously is working? I am starting to think that maybe we should save where we are in another branch, delay this work for this release and then follow-up again with the Enterprise team after 10.9.1 to resolve the remaining issues and implement the changes then. Thoughts?

I think it would be good if we could get the Tracker work implemented this release, so wondering if we should shift our focus there.

jmhauck commented 2 years ago

@chris-fox yes, this works with the previous approach using updateDef.

In terms of thinking about putting this out another release...I had started thinking that way too. Seems like we could work through a few more things with them before fully introducing this. I was getting nervous that as we get through more of the configs we may see some more things like this pop up last minute.

Esri / solution.js

Simplify Enterprise Feature Service creation #661

449

449