AGOL honors Composite but not Simple Relationship class rules

[DougBrowning]

Came across this for Survery123 but posting here since it is a AGOL issue.

To review a Composite relationship class will "manage" the data.  Mainly if you delete a parent it will also delete the children.  This does seem to be honored in AGOL when editing hosted services.

A Simple class is considered "unmanaged" but that is not really true.  What Simple does is if you delete a parent all the children keys turn to Null.  (No idea why they would do that.  The big issue here is if you delete a few parents at once you can now not pull the children back apart.  Highly annoying BTW.)  The funny thing here is that AGOL is NOT honoring this rule like it does for Composite. 

No idea if this is a bug or what.  Anyone seen anything about this?  Anyone know why AGOL is diff than SDE?  I actually like it since Simple in AGOL does not null keys we are able to merge children more easily.  

As a side note

I use this trick to get around this management.  If you are not using the globalid for the relate (which you really should not) I first calculate the key field of the parent to the word Delete.  Then replicate if you have one.  Then delete the parents - this way when it goes looking for children with the key delete it finds none and all good.  The just replace the parents.

If you do use globalid (using built in 123 classes for example) then I instead change the children parentglobalid field to a value like delete.   Then when I delete the parent it cannot find any children and leaves it alone.  Then when I replace the parent I can fix the parentglobalids to the new parent.  Of course the hard part here is having a way to tell the children apart.  Need to delete one parent at a time or have a second field to hold some info that allows you to piece it back together.  This is why I always have my own key field in my data that I pass down to all my repeats.   Saves my butt on the reg.

Hope that helps someone.

[AlfredBaldenweck]

Not to sidetrack your post too much, but you've mentioned not using GlobalID for relationships in a few other posts and I was wondering the best way to do that.

It seems like this(Database Sequneces) is the way to go about it for non-hosted features, but for Survey123, for example, how do you do it for the main table and any repeats?

Is it this (Ticket Problem)?

[DougBrowning]

My IDs are all pregenerated for this project because all the points are premade so that makes it easier.  I add all of these to Field Maps then just pass the id over to 123.  I then pass that id down to any repeats.  123 still does its thing with parentglobalid which is fine.  If either get messed up then other is there.  The main reason here is once you export and import to say SDE globalids fall apart.

If you mean you need to generate ids on the fly I use Arcade for that in another project.  This one they have preset locations but they go back multiple times.  So for each Visit I generate the id based on the Asset ID and the date.

Concatenate($feature.PointID, "_", text($feature.FieldEvalDate, "Y-MM-DD"))

Then I pass this id to the form.  

My guess is you are used to doing a ticket id in sequence.  Like it has to be 1, 2, 3, 4.  That is really hard when you have 100 people offline.   I do not know a way to solve that if offline so instead I generate the id using attributes and a time stamp.  The nice thing about that is that you can use contains later and query all the children of a parent so easy.

I hope that makes sense.

[AlfredBaldenweck]

It does, thank you.

It appears that there isn't really a way to make nice IDs, so I've been becoming more comfortable with ugly IDs.

Thanks!

[DougBrowning]

Agreed.  But one thing I have found is now that we give people relationship classes no one cares about the id much anymore.  They used to sit and query each table for ticket 6599 and now all they do is click show related and done.  Do not even notice the ID anymore.

If you really wanted Ids like that you could run a script each night that calculates it once they are all uploaded.  We do that sometimes to make the Id a real field vs Arcade.

[DougBrowning]

Bump?

[DougBrowning]

Well today I found out that ANY edit to a child record will cause the PrimaryKey to go null if there is no parent record!  This is kinda crazy.  Why is it checking for a parent all the time?  Esp in a Simple relate it should NOT be managing it at all.

I can find nothing at all in the help on this.  We have some historical stuff and it is not complete yet is why we have this.

What is even weirder is it only does it on the replica and not in the DB that we actually do the edits.  So I edit in the base parent replica and no Keys are changed.  When I replicate to the one way child replica it turns the keys null there!  So there is some process going on after a replicate that checks all related keys.  No idea why it would do that, esp in a one way replica.

Anyone else seen this?

thanks