Andras/BoundlessFlowCampus2K

Fork 0

fixes of parking service after latest change in middleware #478 #503

Merged

b24johka merged 3 commits from fixes/parking-service-#478 into team_1_week_3

2026-04-24 09:50:12 +00:00

a24sakma commented

2026-04-23 09:12:55 +00:00

Collaborator

Changes in this pr

This is an adoption on the parking service after latest changes in the middleware.

# Changes in this pr This is an adoption on the parking service after latest changes in the middleware.

a24sakma added the

backEnd

API

labels

2026-04-23 09:12:55 +00:00

a24sakma added 1 commit

2026-04-23 09:12:55 +00:00

fixes of parking service after latest change in middleware #478 b0466c41e4

a24sakma added the

needs review

label

2026-04-23 09:13:08 +00:00

a24sakma changed target branch from temp-branch-week-3 to team_1_week_3

2026-04-23 09:21:12 +00:00

a24vinla commented

2026-04-23 09:22:44 +00:00

Collaborator

Will manually merge this into both weekly branches once this PR passes review!

a24julot was assigned by b24johka

2026-04-23 09:22:48 +00:00

b24johka requested review from a24julot

2026-04-23 09:22:55 +00:00

a24julot was unassigned by b24johka

2026-04-23 09:23:01 +00:00

a24julot commented

2026-04-23 10:29:44 +00:00

Collaborator

Review

Whats done

Tested /api/parking to see what data is generated.
Read through the code.

Tested on Windows using Chrome

The application starts.
The only thing that crashed for me was when trying /api/parking/upload in the browser. The page just keeps loading until "504 Gateway Time-out" appears.
Also, I saw that every spotId is the same, it only has a letter as an ID. There should be added a number as well. (Add j++ in the code? Check pictures)
According to the code, I see that we want parkings to have attributes as charging, disabled and reserved. However, this is not passed on to the data that is generated.

Inspected following files

DockerCompose/compose.yaml
generateMockup/parkingMockup/parkingApiMockup/Program.cs
generateMockup/parkingMockup/parkingApiMockup/Spot.cs
generateMockup/parkingMockup/parkingApiMockup/SpotGenerator.cs
readMockup/readParkingMockup/readParkingApiMockup/Program.cs
- Indentation/code styling
  - Indentation looks good.
- Naming convention
  - Naming convention is followed
- Comments
  - Follows standard for the most part, there was a duplicate comment and some comments are missing an uppercase letter in the beginning.
- General code quality
  - Looks good.

What needs to be done

Fix so that every spotId has a zoneLetter and a number.
Clarify what /api/parking/upload should return, and perhaps use a more descriptive name and add a comment.
api/parking/occupy seems unnecessary now that occupied is random. Could this be removed instead?
Fix so that every parking that should be marked as charging etc, actually has charging set to true.

Conclusion

The code look good and I understand the idea! When fixing these thing I mentioned it will be great.

# Review ## Whats done + Tested /api/parking to see what data is generated. + Read through the code. ### Tested on Windows using Chrome + The application starts. + The only thing that crashed for me was when trying /api/parking/upload in the browser. The page just keeps loading until "504 Gateway Time-out" appears. + Also, I saw that every spotId is the same, it only has a letter as an ID. There should be added a number as well. (Add j++ in the code? Check pictures) + According to the code, I see that we want parkings to have attributes as charging, disabled and reserved. However, this is not passed on to the data that is generated. ### Inspected following files + DockerCompose/compose.yaml + generateMockup/parkingMockup/parkingApiMockup/Program.cs + generateMockup/parkingMockup/parkingApiMockup/Spot.cs + generateMockup/parkingMockup/parkingApiMockup/SpotGenerator.cs + readMockup/readParkingMockup/readParkingApiMockup/Program.cs + Indentation/code styling + Indentation looks good. + Naming convention + Naming convention is followed + Comments + Follows standard for the most part, there was a duplicate comment and some comments are missing an uppercase letter in the beginning. + General code quality + Looks good. ## What needs to be done + Fix so that every spotId has a zoneLetter and a number. + Clarify what /api/parking/upload should return, and perhaps use a more descriptive name and add a comment. + api/parking/occupy seems unnecessary now that occupied is random. Could this be removed instead? + Fix so that every parking that should be marked as charging etc, actually has charging set to true. ## Conclusion + The code look good and I understand the idea! When fixing these thing I mentioned it will be great.

zodeletter.png

5 KiB

data.png

39 KiB

comments.png

10 KiB

a24julot requested changes

2026-04-23 10:32:54 +00:00

Dismissed

a24julot left a comment

Collaborator

What needs to be done

Fix so that every spotId has a zoneLetter and a number.
Clarify what /api/parking/upload should return, and perhaps use a more descriptive name and add a comment.
api/parking/occupy seems unnecessary now that occupied is random. Could this be removed instead?
Fix so that every parking that should be marked as charging etc, actually has charging set to true.

## What needs to be done + Fix so that every spotId has a zoneLetter and a number. + Clarify what /api/parking/upload should return, and perhaps use a more descriptive name and add a comment. + api/parking/occupy seems unnecessary now that occupied is random. Could this be removed instead? + Fix so that every parking that should be marked as charging etc, actually has charging set to true.

a24julot removed the

needs review

label

2026-04-23 10:33:12 +00:00

a24sakma added 1 commit

2026-04-23 11:14:38 +00:00

fixed of spot id and now it can by find by attributes 25472cc70d

a24sakma commented

2026-04-23 11:14:39 +00:00

Author

Collaborator

Thanks for the review I can try to answer you.

What I fixed:

*) Good catch about the spotId I missed to add the number. this is fixed now.
*) Fixes of some can be disabled, charging or reserved.

The changes that will be included later on and is not part of this pr.

you shouldn't use this endpoint at all as the endpoint is used for uploading the data via mqtt to dpo/api/parking/upload. We will make this clear when we combine db handler with the mockupapi for roomBooking and parkingApi but it is an experiment and for now this is the solution. I can add a comment in case someone else is wondering.

Explanations:

I think later on we want to be able to click on a parking by a button and make it occupy for now it is just a mockup that simulates the behavior. We can keep the logic.
if you see this no data to upload waiting...` this is a nomal behaivor as there is no more data to upload as I said we will make it better once we know how to combine db handler and mockupapi

Thanks for the review I can try to answer you. ### What I fixed: *) Good catch about the spotId I missed to add the number. this is fixed now. *) Fixes of some can be disabled, charging or reserved. ### The changes that will be included later on and is not part of this pr. 1. you shouldn't use this endpoint at all as the endpoint is used for uploading the data via mqtt to dpo/api/parking/upload. We will make this clear when we combine db handler with the mockupapi for roomBooking and parkingApi but it is an experiment and for now this is the solution. I can add a comment in case someone else is wondering. ### Explanations: 1. I think later on we want to be able to click on a parking by a button and make it occupy for now it is just a mockup that simulates the behavior. We can keep the logic. 2. if you see this no data to upload waiting...` this is a nomal behaivor as there is no more data to upload as I said we will make it better once we know how to combine db handler and mockupapi

Screenshot from 2026-04-23 13-00-55.png

43 KiB

Screenshot from 2026-04-23 13-10-46.png

37 KiB

Screenshot from 2026-04-23 13-11-36.png

51 KiB

a24sakma requested review from a24julot

2026-04-23 11:16:37 +00:00

a24julot commented

2026-04-23 11:39:50 +00:00

Collaborator

Nice work!

What works

Every spot has correctly been updated with charging, disabled and reserved.
Every spot now has a number.

What needs to be fixed

I noticed that now when the spots have numbers, they start on the number 2. Which means that spot A1, B1 does not exist. In the for loop, j starts at 1, so it should probably just be j.

Nice work! ## What works - Every spot has correctly been updated with charging, disabled and reserved. - Every spot now has a number. ## What needs to be fixed - I noticed that now when the spots have numbers, they start on the number 2. Which means that spot A1, B1 does not exist. In the for loop, j starts at 1, so it should probably just be j.

B.png

22 KiB

Ap.png

24 KiB

loop.png

9.1 KiB

a24julot requested changes

2026-04-23 11:40:05 +00:00

a24julot left a comment

Collaborator

I noticed that now when the spots have numbers, they start on the number 2. Which means that spot A1, B1 does not exist. In the for loop, j starts at 1, so it should probably just be j.

b24johka requested review from a24timsv

2026-04-23 11:58:25 +00:00

a24sakma added 1 commit

2026-04-23 12:40:49 +00:00

fixes of starting on 2 spot id 35b7cacbc2

a24sakma commented

2026-04-23 12:41:15 +00:00

Author

Collaborator

@a24julot
Good catch! this was part of the what I got from the new structure.
Now it is fixed:

@a24julot Good catch! this was part of the what I got from the new structure. Now it is fixed:

Screenshot from 2026-04-23 14-41-08.png

42 KiB

a24sakma requested review from a24julot

2026-04-23 12:42:15 +00:00

a24julot commented

2026-04-23 13:25:28 +00:00

Collaborator

Great job! Everything is fixed according to me, @a24timsv will also review as he has a better understanding of the structure than I do.

a24timsv commented

2026-04-23 20:03:25 +00:00

Collaborator

Might be going on a bit of a rant here, but I just want to 100% understand what's going on.

As of right now, the dataflow of everything in the parkingApiMockup is all over the place. It looks as it is designed to simulate parking sensors that randomly change with the SpotGenerator, but it also looks as the SpotGenerator accesses some database directly, skipping MQTT entirely or going backwards in the dataflow.

If we are simulating hardware, as the tempSensor does, the dataflow is strictly:
generateMockup -> readMockup -> MQTT -> middleware -> Postgres -> Service/API -> frontend.
This flow is easy to grasp and keeps everything clean. I think that the tempSensor is a good template for doing sensors overall.

If the intent is to create a parking spot API, with the ability to set and get spots, then we are not simulating hardware anymore. I know that Andras is mentioning "an API to connect the subsystem" in #42. But I don't really know what the subsystem would even be and why it would be needed. To me, a parking service (like the one on Sandtorget) just uses sensors of some kind to count or keep track cars.

It is completely fine to create something bigger if you think that it's a better solution, but I would like some explanation of how data would flow in this kind of system. What components talk to what? What layer talks to which and how? Is there some form of model or similar?

As for

I think later on we want to be able to click on a parking by a button and make it occupy for now it is just a mockup that simulates the behavior. We can keep the logic.

it comes down to, again, what kind of thing we are building here. But we should try to create a scope for this feature so we don't keep on expanding something all the time so it never actually completes.

Might be going on a bit of a rant here, but I just want to 100% understand what's going on. As of right now, the dataflow of everything in the parkingApiMockup is all over the place. It looks as it is designed to simulate parking sensors that randomly change with the SpotGenerator, but it also looks as the SpotGenerator accesses some database directly, skipping MQTT entirely or going backwards in the dataflow. If we are simulating hardware, as the tempSensor does, the dataflow is strictly: generateMockup -> readMockup -> MQTT -> middleware -> Postgres -> Service/API -> frontend. This flow is easy to grasp and keeps everything clean. I think that the tempSensor is a good template for doing sensors overall. If the intent is to create a parking spot API, with the ability to set and get spots, then we are not simulating hardware anymore. I know that Andras is mentioning _"an API to connect the subsystem"_ in #42. But I don't really know what the subsystem would even be and why it would be needed. To me, a parking service (like the one on Sandtorget) just uses sensors of some kind to count or keep track cars. It is completely fine to create something bigger if you think that it's a better solution, but I would like some explanation of how data would flow in this kind of system. What components talk to what? What layer talks to which and how? Is there some form of model or similar? As for >I think later on we want to be able to click on a parking by a button and make it occupy for now it is just a mockup that simulates the behavior. We can keep the logic. it comes down to, again, what kind of thing we are building here. But we should try to create a scope for this feature so we don't keep on expanding something all the time so it never actually completes.

a24sakma commented

2026-04-24 08:04:40 +00:00

Author

Collaborator

@a24timsv
The data flow is not in all over places. I can explain why

We have parkingapimock map:

This handles all endpoints that gets requested by the fronted.
The endpoints are:

Uploading data into db
request all parking zones
get parking zone by the the zone name

The reason why it connects to db when we query data is because this how it was done it sensorTemp and it is part of the security where we don't manupluate the data the we can make a query that is kind of hard coded.

ONLY insert, update and delete which is part of modifying data and is more sensitive is handled by middle-ware and this is something what we in the team mockup team have decided. I think you were in the discussion we made sure you understood.

The readBooking db handler is:

This was the second design as we tried to follow tempSensor and later on we came to conclusion that this is not optimal and we will move it to parkingApiMockup. Right now this pard db is a temporary solution as in the beginning it was not so much clear for us what and how each micro service will work. This experiment will make clearer the roomBooking and ParkingAPi

Hopefully I made it clear.

@a24timsv The data flow is not in all over places. I can explain why ### **We have parkingapimock map:** This handles all endpoints that gets requested by the fronted. The endpoints are: 1. Uploading data into db 2. request all parking zones 3. get parking zone by the the zone name The reason why it connects to db when we query data is because this how it was done it sensorTemp and it is part of the security where we don't manupluate the data the we can make a query that is kind of hard coded. ONLY insert, update and delete which is part of modifying data and is more sensitive is handled by middle-ware and this is something what we in the team mockup team have decided. I think you were in the discussion we made sure you understood. ### The readBooking db handler is: This was the second design as we tried to follow tempSensor and later on we came to conclusion that this is not optimal and we will move it to parkingApiMockup. Right now this pard db is a temporary solution as in the beginning it was not so much clear for us what and how each micro service will work. This experiment will make clearer the roomBooking and ParkingAPi Hopefully I made it clear.

a24sakma added the

reviewed

label

2026-04-24 08:05:19 +00:00

a24vinla commented

2026-04-24 08:11:01 +00:00

Collaborator

Would it be possible to get a model that shows the data flow and structure?