Optimise how segments are refetched

[theolampert]

When zooming in or panning all segments are re-requested and replaced.

• One potential improvement would be to only re-fetch segments if the new bounding box is outside the old one.
• Another improvement would be to merge new segments with old ones rather than completely replacing them.

[henrymoews]

More ideas to limit the amount of data:

• when requesting segments, the server may not return all details but only the shape and id.
• when the user clicks on a segment, the details (subsegments) will be requested separately by the id
• we may only make requests at a certain zoom level (e.g. 12 or 13)

[theolampert]

@henrymoews My rough idea of supporting this would be something like:

Optionally exclude subsegments:
GET /segments/?include_subsegments=0

Get existing subsegments when clicking a segment:
GET /subsegments/?segment_id={segment_id}

Create/Edit/Delete subsegment:
POST /subsegments/
PUT /subsegments/{id}
DELETE /subsegments/{id}

[henrymoews]

Can I make a counter proposal?

Optionally exclude subsegments:
GET /segments/?details=0

Get existing subsegments when clicking a segment:
GET /segments/{segment_id} (if this is technically easy)

Create/Edit subsegment (always as part of a segment):
POST /segments/ (with the complete segment in the body)

Delete subsegment:
Simply post the complete segment again without the subsegment

I don't see the advantage of handling subsegments separately from their parents. I consider the subsegments as "details" of their segments.

[theolampert]

Sure, looks reasonable, I will reply inline:

Optionally exclude subsegments:
GET /segments/?details=0

Yep, can implement this. So "details" in this sense means subsegments are excluded from the properties field? I will leave them there by default and make the exclusion opt-in.

Get existing subsegments when clicking a segment:
GET /segments/{segment_id} (if this is technically easy)

Yep, I think this already works - e.g https://parkplatztransform-api.herokuapp.com/segments/1 so I can leave this

Create/Edit subsegment (always as part of a segment):
POST /segments/ (with the complete segment in the body)

Delete subsegment:
Simply post the complete segment again without the subsegment

I don't see the advantage of handling subsegments separately from their parents. I consider the subsegments as "details" of their segments.

Yeah, this works, this is what we talked about earlier right? This part in your earlier comment "when the user clicks on a segment, the details (subsegments) will be requested separately by the id" suggested to me you would rather request them more granularly, e.g a user fills in subsegment details in the frontend and this is immediately persisted to the backend regardless of the parent segments state.

I don't feel especially strongly about this so I would be happy to do either, I think it comes down to where we would rather put the logic. The only advantage I see to doing them separately is that it's much more difficult for concurrent edits to clash with each other or overwrite each other. Scenarios in which a segment is edited by more than one person at a time are harder to support when treating them all as one resource. But this comes at the cost of more complexity on the frontend so I understand why you would rather treat them as a single resource, especially when this is probably not a priority for us right now and would be possible to change later. So let's do it your way 👍

[henrymoews]

Okay, so I wasn't expressing well enough what I meant :-)

I feel a little stronger about this because I think we can really get into trouble if we don't understand subsegments and segments as a unit.

So I propose two ways:

1. The later save action wins:
   Two people edit at the same time. The one who saves later, wins.

2. Edit date comparison
   Two people edit at the same time. On save, they have to send the lastEditDate. The server will only accept changes if the lastEdidDate is correct. This means, the first user wins and the second one has to reload the data first and do the changes again.

I prefer option 2) but don't know how much this calculation costs on the server.

I also would move the lastUpdateDate and creationDate from the subsegment up to the segment. (Because I see them as a unit but you can argue on this, of course).

[theolampert]

I feel a little stronger about this because I think we can really get into trouble if we don't understand subsegments and segments as a unit.

Sure, I guess to me this is a difference of perception in that I see them as normalized across two tables. What do you see as potential trouble/issues here? Or is it more an issue of making the feature more difficult?

Calculation-wise on the server it's maybe a few more database queries but not an issue. I would prefer to go with option 1 as it doesn't rely on trusting client timestamps which I would rather not do, I'm probably thinking too much about this particular scenario as it's pretty unlikely and not a priority right now. You're right in that with this workflow created_at and modified_at are less useful on subsegments.

[henrymoews]

Okay, I think of scenarios like this:
User A and B open the same segment. The segment has 4 subsegments. Now, at the "same" time

• A deletes the first subsegment. This means subsegment 1 becomes 0, 2 becomes 1 and 3 becomes 2.
• B edits (the original) subsegment 2.

A saves first and B then sends an update for subsegment 2. The client doesn't know that this has become subsegment 1 in the meantime.

As the result, we have these subsegments:

old 0 -- deleted
0 -- equals old 1
1 -- equals old 2
2 -- equals old 2 with changes
old 3 -- gone and nobody has noted (nor wanted)

About the timestamp: To me the timestamp would be a string which is not interpreted by the client. We could also call it versionNumber, having the same meaning to the client -- just a string. But yes, let's go with option 1 for now.

[theolampert]

Fair enough these are some good points, I see a few ways around it. But we can revisit the whole topic at some point in the future if it becomes a bigger problem.

I will implement option 1 and let you know when you can test it.

[theolampert]

@henrymoews I think those endpoints should be available now but I haven't tested a lot:

parkplatz-transform/parkplatztransform-api@710752d
and
parkplatz-transform/parkplatztransform-api@7205ad7