Modeling Wiki+Lock Feature

[Vido]

Profiles are the points on the map. They represent a waste collection alternative.

• CRUD (create, read, update and delete)
• This CRUD should support photo uploads
• It should be wiki-like (colaborative editing)
• Pimp must be able to moderate the editions
• Catador/Cooperative can claim a already created profile
• Claimed profile are moderated by this claimer (tdb)
• The claimed profiles should support a lock for colaborative editions

---

Source file: catadores_er_xml.zip Unzip and open the XML with: https://www.draw.io/

What are your take on this? Am I missing something?

[ghost]

Nao posso acessar nenhum source file? Nao vejo a mapa 'files' no pimpapp-api.

On Mon, Jan 11, 2016 at 3:12 PM Lucas Vido notifications@github.com wrote:

Source file: catadores_er_xmlzip https://githubcom/PimpAPP/pimpapp-api/files/86064/catadores_er_xmlzip Unzip and open the XML with: https://wwwdrawio/

[image: catadores_er] https://camo.githubusercontent.com/bf8cbdf1e1f97eec41b7f2e5d4b08060ab3e6db5/68747470733a2f2f636c6f756467697468756275736572636f6e74656e74636f6d2f6173736574732f3935363338382f31323234303530332f65636638353039322d623837342d313165352d396634382d633063383266646638306635706e67 What are your take on this? I'm missing something?

— Reply to this email directly or view it on GitHub https://github.com/PimpAPP/pimpapp-api/issues/14.

[Vido]

It seems that the links don't work on email... strange...

Try to open it on Github: https://github.com/PimpAPP/pimpapp-api/issues/14

On Mon, Jan 11, 2016 at 4:21 PM, Katrine Tjoelsen notifications@github.com wrote:

Nao posso acessar nenhum source file? Nao vejo a mapa 'files' no pimpapp-api.

On Mon, Jan 11, 2016 at 3:12 PM Lucas Vido notifications@github.com wrote:

Source file: catadores_er_xmlzip https://githubcom/PimpAPP/pimpapp-api/files/86064/catadores_er_xmlzip Unzip and open the XML with: https://wwwdrawio/

[image: catadores_er] < https://camo.githubusercontent.com/bf8cbdf1e1f97eec41b7f2e5d4b08060ab3e6db5/68747470733a2f2f636c6f756467697468756275736572636f6e74656e74636f6d2f6173736574732f3935363338382f31323234303530332f65636638353039322d623837342d313165352d396634382d633063383266646638306635706e67

What are your take on this? I'm missing something?

— Reply to this email directly or view it on GitHub https://github.com/PimpAPP/pimpapp-api/issues/14.

— Reply to this email directly or view it on GitHub https://github.com/PimpAPP/pimpapp-api/issues/14#issuecomment-170640820.

[fernandobalm]

Se for para escrever em português peço que me avisem.

Friends, Just some ideas more. See what you think. They are not exclusively about Wiki+Lock feature, but is regarding user and login modeling above:

• What about forget password feature? Will be there an email to resend a reset password? Or maybe a secret phrase or a personal data checking? If some of them, maybe some fields can be put in auth_user table or a 1->1 or 1->N extended data table for user.
• What about password blocking due to exceed limit of attempts? Maybe a field with number of unsucceded attempts in auth_user table?
• Rules for user name and password (characters accepted, minimum and maximum size, etc) will be hard coded or will be there a table to parametrize them? A table become easier its change if needed in future, but it would be generate more work to do.
• Will exist status for users? Like inactive, removed, active, etc. By the case a user be removed and don't lose all its historic or just be inactivated. In this case a status field in auth_user table could solve. This points become more relevant due to historic records in profile_page_hist, in case a catador leave the system and also due to rating, in the same case or when a user leave the system.

Regarding lock, I thought about a question:

• Will be possible for PIMP to unlock a profile? I thought about it in case of false information given by a catador or some misleading marketing or even bad intentioned person? I guess this will not affect this database model, but could be considered in app implementation.

Regarding rating, in the future, if we have lots of records, maybe we need to create consolidated tables due to performance issues.

[Vido]

Sorry @fernandobalm, I didn’t post all the information. I’m fixing that! I skipped the definition and jumped into ER model. However, I believe you received a file called ‘features.pdf’, which presents some key ideas from this project.

• About points 1 to 3: We are going to have OAuth 2.0. I would not worry about this low-level authentication details.
• About point 4: Django auth.user has the is_active, therefore the soft-delete behavior proposed is a framework resource.
• About point 5: Yes, moderators can revoke permissions.

---

@fernandobalm, yes, rating might grow and become a huge table.

I don’t know... profile_page_hist and profile_page_trans smell like over-engineering. I’d like hear some alternative takes on how to store historic editions.

The challenge of keeping the history consists in how the PK changes when a new object is created. Here is an example: We have the profile_page_trans.id=1 and photo.profile.id=1 (photo has a FK to profile_page_trans). If this profile is edited, it is replaced by profile_page_trans.id=2. This causes photo.profile to reference the old object.

And before you say: Yes, there are tricks to fix this. But we are modeling our database from scratch, we can kill bad code in it’s nest.

Today’s lesson: Have FKs only to immutable PKs

[fernandobalm]

Is this change in PK when a record is being updated a mandatory characteristic of Django? Database itself doesn't need to change PK, once you are just updating fields in a record. Isn't possible (and desirable) to disable it? Anyway, if Django or any used tool requires it, could we update all FK's simultaneously (by a trigger for example)? In this case I guess we could not have FK database constraints. Integrity could be in application level. If I understood, If database has active FK constraints, we will not be able to update or remove PK with an orphan FK child. I guess it will occur a referential integrity error. And vice versa.

[Vido]