[Feature] Add RELATED-TO;RELTYPE=CHILD property to parent Journal items for sub Notes

[rogercreagh]

Is your feature request related to a problem? Please describe.
Currently sub-notes for Journal items have a RELATED-TO: property set to the parent item (the Journal item) uid

However there is no corresponding RELATED-TO;RELTYPE=CHILD: set on the journal item.

This means that if you are fetching only VJOURNAL items with a DTSTART, or with a specific UID, you have no way of knowing that there are related Journal Items with no DTSTART (ie Notes)

I guess this is not a problem with jtxB as I think you are always dealing with the entire set of VJOURNAL items so will always find the child items to tie back to the parent.
Are you setting the RELATED-TO child parameter for Journal items with a child ToDo?

Describe the solution you'd like
If an item has a parent-child relationship with another item of the same type (eg Journal and Note - both VJOURNAL items) or a different type (eg Journal and Todo) then both parent and child should have the relevant RELATED-TO property set.

Describe alternatives you've considered
Not being able to find related child items without looking through the entire dataset.

[patrickunterwegs]

Hey @rogercreagh ,
let me also convert this to a discussion.
The short answer is NO, jtx Board 2.x does not set the CHILD relationship and I really don't want to bring this back.

The long answer is:
When I first started jtx Board, I was thinking the same way. I thought it would make things easier when you need to show the parents or the children of an entry. So I was even physically storing both ways, the parent and the child relationship.
However, this got so complicated in some places and caused so many problems, that I decided to drop the CHILD relation and only kept the PARENT.
Why?

1. When you have both relations, every time you add a new child, you also have to update the parent, which also causes an additional entry to sync
2. The same for deletions, you delete a child, you need to update the parent.
3. This gets particularly messy when thinking of the sync. All other apps that I know don't use the CHILD relationship, only the PARENT. When you want to use the CHILD-relationship, you need to create it artifically - which I did in jtx Board 1.x physically. Changing entries from another app just for the sake of fullfilling the needs of the own app is also not a good practice.
4. Mass deletions through the sync are particularly hard to do, as you need to change every parent afterwards as well to update the related-to. But sometimes you just don't know which entries were deleted through the Android content provider and it's not clear if orphaned related-to entries are really orphans or if an entry is just missing.
5. After all using only the PARENT relationship brought more advantages than disadvantages and now it works properly and reliable.

So I stronly recommend you to not use both relationship types and stick with the PARENT!

[rogercreagh]

OK. That's interesting that you've been down the same path and gone on further. I see the disadvantages and now thinking about it, it only requires a simple join to check for child items in a related table (1 to many) in the local database.

The only issue is if I'm not doing a full sync from the server and just collect a new or updated item which now has child items - I won't know about them until I do a full sync. But even then I could just do a check to ask the server for any items that have a related-to property with the parent of the new/updated item.

I started off thinking that doing a more or less full sync every time was a waste of resources and time but I've found on testing that getting 300 items from the server in one batch is only a fraction of a second slower than just getting one. (2.7 secs as against 2.5).

What I don't fully understand is why jtxB is usually taking 45secs to sync through Davx5 even if I turn off all other calendars and collections in Davx5. If I sync all four calendars on the server it takes over a minute - and none of them are particularly large it seems to me. That is what set me thinking to avoid full sync when possible, but in practice it looks like directly polling the server without Davx5 is acceptably not slow. (using php curl put/get)

[patrickunterwegs]

Hey, sorry for the late reply, I somehow missed your answer.
Yes, finally that's what I did, now I'm just resolving the children of a parent only through the children's RELATED-TO parent relationship.
I'm not sure about your architecture, but as entries with a related-to property are anyway standalone entries, in case of DAVx5 they do a check of the eTag and sync only the new/changed entries. I'm not so deep into the server-side sync, but if you're interested or if you have any specific questions, we can also check with DAVx5 or just mention them here.

About the sync time: Indeed that's a bit weird. I'll need to check improvements anyway in the future about the efficiency of the sync.
But did you check the time through the logs or through the app? Because in Android there's that sync-framework that takes care of scheduling and triggering the synchronization. jtx Board can only query if a sync for a specific account within the sync framework is active - but as I've seen having an active sync doesn't necessarily mean did it is doing the sync, it ususally gets active a bit before the sync actually starts and then sends the stopped signal only a few seconds after it's done.
So in your case I'd say whatever works best 😉