admin/minutes-item-vote-event-minutes-item-schema

[isaacna]

Pull request recommendations:

• [x] Name your pull request your-development-type/short-description. Ex: feature/read-tiff-files
• [ ] Link to any relevant issue in the PR description. Ex: Resolves [gh-12], adds tiff file format support
• [x] Provide context of changes. Adding proposal for vote, minutes_item, and event_minutes_item based on the front end query requirements. My logic behind nesting duplicate information was to only add information that needs to be accessed easily/without joins, such as nesting matter_name and matter_title directly into vote.
• [ ] Provide relevant tests for your feature or bug fix.
• [x] Provide or update documentation for any feature added by your pull request.

Thanks for contributing!

[tohuynh]

Can we combine minutes_item and event_minutes_item into just minutes_item? Seems like there's some overlap between the two. Is there a reason why the two are separated?

[isaacna]

Can we combine minutes_item and event_minutes_item into just minutes_item? Seems like there's some overlap between the two. Is there a reason why the two are separated?

They are separated since event_minutes_item refers to a specific instance of a use of a minutes_item in an event.

I think combining them could make a minutes_item instance to get bloated and hard to link to vote, because votes can happen on the same minutes_item over multiple events with different decisions.

@JacksonMaxfield has a better understanding of the context so could give some more input

[tohuynh]

They are separated since event_minutes_item refers to a specific instance of a use of a minutes_item in an event.

I think combining them could make a minutes_item instance to get bloated and hard to link to vote, because votes can happen on the same minutes_item over multiple events with different decisions.

@JacksonMaxfield has a better understanding of the context so could give some more input

I see. I just worry about one query. In the details tab of the event details page. To display the details tab we would query event_minutes_item using event_id. For the event_minutes_item that are matter-related, we have everything we need (matter_name and matter_title). But for non-matter event_minutes_item we would have to query minutes_item to get the name field. That's maybe around 5 more queries. It's no big deal though.

[isaacna]

But for non-matter event_minutes_item we would have to query minutes_item to get the name field. That's maybe around 5 more queries. It's no big deal though.

If that's the case and too many joins are a concern then we could just add minutes_item_name (and any other data needed for quick access) in the event_minutes_item table like this:

minutes_item: {
    minutes_item_id: str
    minutes_item_name: str
}

Since this is a non-relational database I think having duplicated data is preferred over having excessive joins from a performance and design view.