Create database model

[ravirani]

Add the following objects to the database schema:

• Business
• Person
• Address

[TomHarte]

I think I ended up at quite a different overall schema, working directly from the forms on hackthehood.org — see https://github.com/martasmith/HackTheHood/wiki/Schema for my breakdown. Is that acceptable? Or better? Or worse?

[martasmith]

Thomas, it looks great! I have a couple of observations:

• I like the website page table. I think we need that.
• Should we have the resources field omitted from the WebsitePage table and crate an additional mapping table called business-resource, which would map business id's to resource id's?
• Is there a reason why we need a separate table for imageResource and String resource? It seems like your pageResource table is sufficient, unless we are planning on adding additional complexity to image resource and string resource data. -I think it would be a good idea to separate the business model from the contact/person/user model.
• We seems to be missing a table for address, or should it be part of the business and contact tables?

Disclaimer: I'm not as experienced as you are, so my suggestions might be incorrect. Please also solicit Ravi's feedback and correct me where you think I have mistaken. This is a learning experience for me and probably all of us.

[TomHarte]

Especially in California, I can easily foresee string resources needing to be localised, which would make StringResource contain a mapping from language code to text. But all we’d have to do is change StringResource.

For ImageResource it struck me that the charity is in an odd position: from what angle, etc, you photograph the front of the business should be a design decision, related to how you want to frame the surrounding content. But at the minute it’s a decision made by whomever takes the photo, which is an entirely different person. So it’s easy to imagine that version 2 might allow the business to supply many different photos so that the student can pick whichever fits best. In which case the ImageResource would end up containing an array of options (possibly with notes).

So, yes, in both cases I’m thinking ahead.

I ignored consideration of exactly how relationships would be stored in database terms owing to not yet having used ActiveAndroid. If it doesn’t automatically do appropriate join tables then, yes, we’ll need to come to a decision on our own.

I omitted business address by accident. Will revise. And advise.

[martasmith]

Thomas,

That makes sense. Thanks for the clarification. How about the separation of business and contact. Should we separate them or keep them as one single entity? I was thinking that person would be an entity and contact and business owner would extend person. Though, for the scope of this project, it might be an overkill.

[martasmith]

@ravirani please take a look at the schema Thomas implemented so we can move forward with the creation of the models.

[rrani]

This looks good as a first pass. Also, relationships management is pretty easy and intuitive in ActiveAndroid.

For the schema, I think we might have to stick to something like this instead of the ideal one where we make the Person, Business, etc. as true model objects. This is because if we are not able to post to Google Sheets for some reason, we might have to ask them to use Parse as their workflow. And Parse database view looks like a spreadsheet.

[martasmith]

Sounds good to me! So we need to investigate whether or not we can post to google docs by creating a test post. Ravi, can you create a ticket for this task and investigate this by Monday, so we have all the basic implementation details finalized for Sprint 1 (Monday)?

[ravirani]

Sure

[TomHarte]

The schema has been updated to sever user from webpage and create a one to many relationship there. The hypothetical use case is that an on-foot agent is partway through setting up a business but is unable to finish. They agree to return later in the week. In the interim they want to set up other businesses.

It also adds the business address that was accidentally omitted. It is currently one text field — following the HackTheHood form — plus latitude and longitude, should we want that for our pitch deck.

I therefore believe this task to be complete and will mark it as such. We can always remove that tick if I've missed anything else.

[martasmith]

Thanks, Thomas, I took a look at your updated schema. It looks good to me. The only thing I see is, that chronologically, the user fills in the business information and contact (user) information, so when we first initialize the website model, we are not able to add all the required fields for the object creation in the database. Also, currently the address field is broken into separate fields, but I could concatenate them into one string before adding it to the DB if that works better. As a final observation, I noticed that the user has a field websites, which will be an array of website objects. According to Hack the Hood, they only build one website per business, and up to 3 pages per website. Does this change things?

[TomHarte]

With a little further reflection I think you’re right about the need for a one-to-one relationship between user and business. I was, as I said, thinking about the canvassers but I guess they’ll just create an account for each business.

I don’t see your chronological problem. Specifically:

User is created; Website and is created and attached to User; Address is created and attached to Website; WebsitePages are created and attached to Website; PageResources are created and attached to WebsitePages.

What’s the problem?

I put only a single string into Address to mirror the web page; we can do whatever we want I guess — it can be packed into a single string for submission to Google Docs. Just tell me what fields we need (or edit the wiki, or the code).

On 12 Oct 2014, at 19:11, martasmith notifications@github.com wrote:

Thanks, Thomas, I took a look at your updated schema. It looks good to me. The only thing I see is, that chronologically, the user fills in the business information and contact (user) information, so when we first initialize the website model, we are not able to add all the required fields for the object creation in the database. Also, currently the address field is broken into separate fields, but I could concatenate them into one string before adding it to the DB if that works better. As a final observation, I noticed that the user has a field websites, which will be an array of website objects. According to Hack the Hood, they only build one website per business, and up to 3 pages per website. Does this change things?

— Reply to this email directly or view it on GitHub.

[ravirani]

Keeping the address components separated allow us to do interesting things. I would recommend keeping it that way.

[martasmith]

Thomas,

Your Website model has a required field "pages" that is not going to be available to populate until the business is approved. So when the app collects the first round of data, we have some user data and business data. If we have a separate business data model, we can initially populate the user and the business at the initial data collection phase. Another option would be for the required "pages" field in the website table to have a default value to allow the creation of the website data model at the website application stage. (sign up for a free website screen) And come to think of it...do we need a field called "approvalStatus" or similarly named, that would be used to store the current approval process status in there, such as approved, pending, waiting for more info, denied, etc..?

[TomHarte]

That’s just because I’ve not been using optional as a synonym of Nullable. I directly foliowed the HackTheHood web page on what’s ‘optional’ and in this context optional just means: can still be absent once all data is input.

Which, obviously, cuts directly to the issue of chronology.

On 12 Oct 2014, at 20:35, martasmith notifications@github.com wrote:

Thomas,

Your Website model has a required field "pages" that is not going to be available to populate until the business is approved. So when the app collects the first round of data, we have some user data and business data. If we have a separate business data model, we can initially populate the user and the business at the initial data collection phase. Another option would be for the required "pages" field in the website table to have a default value to allow the creation of the website data model at the website application stage. (sign up for a free website screen) And come to think of it...do we need a field called "approvalStatus" or similarly named, that would be used to store the current approval process status in there, such as approved, pending, waiting for more info, denied, etc..?

— Reply to this email directly or view it on GitHub.

[martasmith]

I think a direct correlation of nullable in the DB and what is indicated as optional on the Hack the Hood website would be a good way to go. However, while creating my screens, some of what Hack the Hood have marked required seemed questionable to me. But that part, we can discuss tomorrow during our lab session, as we walk through the user flow screens and compare them to the current website functionality.

[TomHarte]

I don’t see that’s possible. If you do not allow the local store to accept, say, a page for which the body text has not yet been written then, in effect, you don’t allow persistence in a whole bunch of normal cases.

On 12 Oct 2014, at 21:03, martasmith notifications@github.com wrote:

I think a direct correlation of nullable in the DB and what is indicated as optional on the Hack the Hood website would be a good way to go. However, while creating my screens, some of what Hack the Hood have marked required seemed questionable to me. But that part, we can discuss tomorrow during our lab session, as we walk through the user flow screens and compare them to the current website functionality.

— Reply to this email directly or view it on GitHub.

[martasmith]

Yes, that is why I mentioned that we need to discuss what should be marked as required in our app. When in an app or in a website a field is marked required, usually the validation process will not let the user submit the data. So we should use it as sparingly as possible. I, personally, have always built user interfaces that match the database schema optional/required fields. However, I am opened to new implementations, but I would like to solicit @ravirani's take on this as well.

[TomHarte]

The argument as far as I’m concerned is:

local persistence ensures the app maintains a consistent state between launches; and the app is intended to submit data to HackTheHood only once it’s fully collected; so there’s therefore no reason for a connection between what is locally nullable and what is remotely required.

It’s a democracy so, yes, let’s have the discussion as a group if there’s any controversy.

On 12 Oct 2014, at 21:58, martasmith notifications@github.com wrote:

Yes, that is why I mentioned that we need to discuss what should be marked as required in our app. When in an app or in a website a field is marked required, usually the validation process will not let the user submit the data. So we should use it as sparingly as possible. I, personally, have always built user interfaces that match the database schema optional/required fields. However, I am opened to new implementations, but I would like to solicit @ravirani's take on this as well.

— Reply to this email directly or view it on GitHub.

[martasmith]

Ok. I see what you mean now. I was not aware that this is what we are doing. It makes a lot more sense now. However running it by Ravi still won't hurt.

[ravirani]

I agree with Thomas's point that we need to just persist data as it is entered to allow users to enter info in multiple sessions. We won't submit to the server unless all the required info is present. Either way, the UI would reflect the approach.

[martasmith]

Ok, sounds good to me!