Introduction of cart workflow

[6R1M5L07H]

The feature includes two models: cart and cart item. The cart is created as an intermediate step between the selection of the goods so that a customer can collect items in said cart as cart items and check them out in one step.

Resolves request #69

[ilyarolf]

There's still a lot of work to be done before pouring in that PR.
General Comments:

1. Use an approach that is already in use at the moment:

• Commas at the beginning instead of at the end;
• Distinguish models for SQLAlchemy from previous models;
• Products in cart can be shown the same way as Subcategories.
  All this is unnecessary and makes the code heterogeneous.

2. There should not be any comments in the files, only TODO is allowed.
3. Do not add useless files that are not used anywhere, even if you plan to use the code from these files later, they are of no use now.
4. Don't create formatting changes, this causes the file to show up as changed, even though the actual essence of the file hasn't changed. This increases the cognitive load for the PR checker.

[6R1M5L07H]

* Commas at the beginning instead of at the end;

Done

* Distinguish models for SQLAlchemy from previous models;

Please elaborate

* Products in cart can be shown the same way as Subcategories.
  All this is unnecessary and makes the code heterogeneous.

IMO these are two separate entities. If any, the CartItem resembles more the Buy Entity but still I think that you need a different entity. Here is why:

• Subcategory (which I would rephrase as "Article" tbh, but that is something different) is something static in the DB and is independent from a User's class or a Buy, so it exists from my understanding to represent the Article Catalogue
• Buy is bound to the User and exists for the purpose of having a history
• CartItem however is meant to be volatile since it only exists while the Cart exists and the Cart only exists until its content - the CartItems - are transformed into Buy objects. The CartItem is imo needed to implement the payment process on a "pay as you go" approach instead of the existing deposit approach

Happy to discuss

2. There should not be any comments in the files, only TODO is allowed.

I'll follow your direction, although I think that comments don't hurt anyone. I had to understand your way of thinking for some time and comments would have helped me a lot. If you change your point of view here, let me know, please. Until then, I remove the comments (I do not mean commented code but actual comments btw)

3. Do not add useless files that are not used anywhere, even if you plan to use the code from these files later, they are of no use now.

Agreed and removed.

4. Don't create formatting changes, this causes the file to show up as changed, even though the actual essence of the file hasn't changed. This increases the cognitive load for the PR checker.

Agreed, will improve myself here, thank you

[ilyarolf]

@6R1M5L07H

1. About SQLAlchemy models.
   
   
   Use a model field format similar to Users, i.e.
   Column({type}, nullable={value}, etc...)

Please elaborate

• Products in cart can be shown the same way as Subcategories.
  All this is unnecessary and makes the code heterogeneous.

What was meant here is that you need to rework the way you describe the model fields. What I described in the 1st paragraph with screenshots.

3. About the comments in the code. Try to use inline comments only in complex cases, for example in the db.py file it is described in detail why it is necessary to import SQLAlchemy models even though they are not used in this file, and also it is described why SQLCipher will not work on Windows.
   Comments that I will always be glad to welcome are PEP8 docstrings.