feat(schema.json): Adiciona novos campos de subeventos e oficionas re…

[xflprflx]

#14 - [E3] CMS: Suporte a cadastro de atividades em eventos

🆙 CHANGELOG

• Criação de relacionamento entre evento e subeventos. (Um evento possui * subeventos)
• Criação de relacionamento entre evento e oficinas. (Um evento possui * oficinas)
• Renomeação do campo data para data_inicio
• Adição do campo data_fim

⚠️ Me certifico que:

• Não deixei nenhum novo warning, erro ou console.log nas minhas modificações
• Solicitei code review para 2 pessoas

⚠️ Como testar:

• Acesse a branch 14/Suporte-a-cadastro-de-atividades-em-eventos
• Acessar o CMS utilizando o comando 'yarn develop'
• Entre no Strapi CMS (http://localhost:1337/admin) e cadastre eventos com todas as informações pedidas.
• Tente cadastrar um ou mais subeventos
• Tente cadastrar uma ou mais oficinas
• Teste o retorno no postman com a url abaixo
• Aplicação não deve conter nenhum erro, warning ou console.log
• Alteração proposta no card foi implementada.

http://localhost:1337/api/events/?populate=parceires&populate=subeventos&populate=fotos_evento&populate=oficinas

[yrachid]

Tem algum motivo específico para usarmos snake_case ao invés de camelCase? Esses campos são colunas no banco de dados? Se não houver nenhuma restrição, acho que aderir ao camelCase aqui poderia ser uma boa, já que consumimos esses dados diretamente no front-end.

[yrachid]

A menos que isso se torne uma coluna no banco de dados, pois o Postgres não lida muito bem com camelCase, aí se esse for o caso, é mais fácil deixar com snake_case mesmo.

[xflprflx]

Neste caso, casualmente, usamos snake_case para seguir a convenção do projeto.
Mas pelo que encontrei a partir da versão 4 do Strapi, o padrão é snake_case. (https://docs.strapi.io/dev-docs/migration/v3-to-v4/data/sql#column-name-casing)
Estes campos vão se tornar colunas no banco de dados sim.

[barbaraanger]

Seria legal depois ver para padronizar isso então, tornar uma regra pro cms.