Schema changes to hosted feature layers after creating a view with the Join Features tool

[AleydisG__Pere]

This article (June 2018) says that feature layers participating in view layers with joins can't have their schema altered.

Is this information still valid?

We've been experiencing this with a hosted feature layer which may need to have changes to some field domains (from the Data tab in the item details page). This means we'll have to delete and recreate the view and the web map each time users ask for a change in a domain. And some extra steps to make apps use the new web map.

The weird thing is that in a test feature layer we were able to change field names and domains in AGOL after creating a view with it using the Join Features tool. I've been unable of reproducing this again but it makes me think there's an exception to this limitation. Am I right?

[Anonymous User]

Hi Aleydis,

To my experience and knowledge the article is still valid and I am not aware of an exception to this limitation - I ran through the workflow a couple of times to be sure and my domains and field names in each Hosted Feature Layer participating in the join-created View became non-editable. 

That said, if you find a workflow that consistently reproduces the behavior we would definitely want to test it out and log an issue on our end, that would not be expected behavior and could have some serious consequences for the integrity of the View. 

Hope that helps,

-Peter

[AshleyHayes2]

Hi Peter, 

I am unable to make schema changes to one of my hosted feature layers that has views, but I did not join any features to create those views.  Are there any other limitations related to views, etc. that would be prohibiting me from making schema changes?   

Thanks!

[Anonymous User]

Hi @AshleyHayes2 - I have seen a couple Support cases come in where a similar issue is reported, but we have not been able to reproduce the issue or identify a bug yet. How many views do you have associated with the service?

At the Rest endpoint for the parent layer, you can see the sourceSchemaChangesAllowed property. This will confirm if the service is not allowing schema changes. To see this, select the View option next to the service URL at the bottom of the Item Details overview page. This opens the Rest endpoint in html format. Add f=pjson&  to the URL so that it looks like .../FeatureServer?f=pjson&token=agfykD... then press enter. Look for the following property - for your service I would expect it to be false. 

If there aren't a lot of view layers and you are able to re-create them, deleting and re-creating the views should reset this property and resolve the issue. If this troubleshooting step is not feasible with the number of views you have, let me know and I can help get a support case started. 

Thanks,

-Peter

[AshleyHayes2]

Hi @Anonymous User ,  Thank you for the reply!  That property is actually showing "true" for my service.  I don't mind deleting and re-creating my views once if that is my only option, but I would like to try to get a better understanding of what may be happening in case it happens again.  Any further suggestions?  Thanks again, Ashley

[Anonymous User]

Hi Ashley, that's interesting - not what I expected. Deleting and recreating the views may still be a good troubleshooting step, but it doesn't seem like the issue is caused by this property.

When did you start to notice the issue? Can you filter by the item ID in an activity report to see if you can correlate an update made to the item with the behavior? This is definitely something that Support can help dig into further via a screen share, but it's hard to speculate on what might be happening/how the service got into that state without a much closer look. 

Hope that helps,

-Peter

[spatialcase]

I'm surprised that this post has not had more participation as the difficulty in modifying a feature layer schema with existing join layers is a serious problem in production environments.  Making a minor change, such as modifying a domain, requires that all join layers on that layer to be dropped and then recreated afterwards.  Then all maps/apps that rely on those join layers need to be reworked.  It is not something to be taken on lightly!

I would love to see something to lessen the burden and risk of making schema changes to these layers.

Regards, Graham

[Anonymous User]

Hi @spatialcase thanks for the comment. Making it easier to modify schema on a hosted feature layer with a view created from a join is something the Development team is looking at. 

[CathyAlmberg]

please tell them to hurry. Its 1130pm and I am up recreating AGO solutions just to add crew member names to a pick list. I cannot do this during production hours. And since the data is used across web maps, apps, dashboards, and mobile solutions, it takes HOURS.

[MundellEarth]

Hi @Anonymous User - if there a development ticket on this topic? I'd like to vote on it!