-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Analyse and design internal API for data select functions #8
Comments
[In Czech Language] Možná vycházet z toho, co by naše výběrové funkce měly dělat. V jedné tabulce to bude: V tabulce stanic: Jednotlivé funkce by mohly vracet: denni_data Bez uvedení parametrů by mohly vracet všechna dostupná data. Atributy funkcí by tedy mohly být: get_daily_average_temperatures(cursor, date_from=None, date_to=None, meteostations=None, limit=None) Vracet by ty funkce mohly buď pouze sestavený SQL dotaz, který by se následně předal k vykonání (pak by nepotřebovaly kurzor), nebo by vracely výstup z databáze, nebo by vracely už data, přeskládané do nějaké struktury. (Jaké?) Data by měla být v takové formě, abychom s nimi mohli snadno pracovat dál. |
V commitu 5cee051 do větve issue_8 jsme přidali jednu funkci, která by měla vyplivnout denní průměry. Máme připravenou další na roční, ale chceme dneska na srazu ještě prodiskutovat jak bychom měli postupovat dál. |
When we have measurements data, we can use them many ways.
(API = Application Programming Interface)
Description API in Czech (V kontextu naší aplikace, API popisuje, jak se daná funkce volá a co provede (resp. co vrátí jako výsledek)).
To have good designed API is proven way how to keep program less complicated, easier readable and better usable.
How we will use that data?
How we design functions headers, which attributes we should use?
The text was updated successfully, but these errors were encountered: