federico-fiorini / data-layer Goto Github PK

As the coverage is not in the whole city we need to provide a resource where we can manage it. We can use the granularity of a neighbourhood using the name provided by the post office according to a given ZIP Code.

So it is important to have stored the city, neighbourhood and state (region), with a code that can be linked later to the cleaners, this way, later on, we can check the availability based on the cleaner coverage.

In Brazil the addresses are strongly referenced to the neighbourhood name, it is important to have this information stored, specially for the cleaning people.
See bellow an instance of data model

"addresses": [
    {
      "city": "Florianpolis",
      "country": "Brazil",
      "flat_number": "10F",
      "house_number": "10",
      "orders": "http://localhost:5001/api/v1.0/address/13/orders",
      "post_code": "89770-000",
      "street": "Rua Dr. Getúlio Vargas",
      "neighbourhood" : "Itacorubi",
      "url": "http://localhost:5001/api/v1.0/address/13"
    }
  ]

In some cases (e.g. schedule and address), we need to list the options and ask the user to choose one, and on that cases we need to have a unique reference each of these resources.

We have some alternatives, such as put the resource link or search for the reference in the link, but it can represent showing information about our database and data_layer that we could keep hidden.

Include new attributes to the cleaners. a short description (which will include their experience and personal quote) and a int value for five stars reviews, and a text for "last review".

At some point, in the address or in the user it is important to store the phone number of the user. This allows the staff to contact the people in case the place is not being found or some problem happens with the payment.

In the future it can be a valuable information to store all the searches and request, specially when they are not finished.

For creating the timetable of prices we need to read the schedule to see who is available and when, for now we can simply read all the schedules and process them, but, it would be more interesting if in a future release of the system we could have a function that returns just the schedules between two dates.

e.g.

GET
/api/v1.0/schedules/[start week]/[day]/[end week]/[day]

or

GET
/api/v1.0/schedules/?start-[start week]-[day]&end=[end week]-[day]

As we said, we want to have a way to reserve a schedule from when the user clicks 'buy' to when we get the notification of payment from PagoSeguro.
Implement it as a new type of schedule (marked with a flag).

For the bookings we need to have some sort of unique reference that can be seen on a public way. It can be something informative thing "ddmmYYYY[some_index]" or just some index.

There is also the need of storing on the server the payment transaction code (e.g. BD0C57F2-B1B1-45E8-9F5E-73512F1E2942) for further checks.

Once we involve payment and transactions, it is important to create a disable method for avoiding loosing information.

It also includes adapting the method of new users once the user can be deactivated and try to register again. (Can be discussed to be solved partially in the Business Layer)

Once the prices may change (e.g. the price may increase a bit tomorrow), we cannot calculate it every time we check a booking, therefore it is important to store the agreed price when the service was booked.

Create a table where we can store the information regarding the users that tried to register but did not find our service in their location.

Include on this, e-mail and zip.

When trying to insert the following JSON into /api/v1.0/user/39/addresses an error on City name is returned, when the vowel "ó" is removed, it works again.

{
"street": "streeeet",
"house_number": "10",
"flat_number":"10F",
"post_code": "89770-000",
"city": "Florianópolis",
"country": "Brazil"
}

The attribute "name" is a nice way to refer to certain Service but still is necessary to have some human readable information to attach to the fields when showing them.

An instance of JSON with such attributes is given bellow:

"services": [
    {
      "name": "fridge",
      "description" : "Clean the Fridge",
      "time": "0:30:00",
      "type": "normal"
    }
]