DIVIDA TÉCNICA: Framework objeto relacional

[marceloTerencianiIFPR]

O Java e o JavaScript estão compartilhando a mesma base de dados.

Sequelize e Hibernate estão disputando a criação do banco de dados e não está saindo igual. Devemos escolher qual terá poder sobre a criação do banco, mas precisamos manter o mapeamento entre as duas aplicações para que consigam trabalhar simultaneamente - para fins de testes.

Não tenho certeza se o Sequelize oferece suporte somente a leitura do banco, sei que o hibernate oferece.

Uma alternativa é utilizar o Knex na aplicação Electron.

[OAllanFernando]

Olá. O teste foi apenas rodas as aplicações na mesma base ? O sequelize verifica a existência do banco e se houver não cria uma nova. Os dados ficaram diferentes ? Eu posso ter mapeado errado.

[marceloTerencianiIFPR]

Ao usar a mesma base está sendo gerada uma nova tabela.

Não é necessariamente um problema, só temos que decidir qual estratégia adotaremos.

[OAllanFernando]

Olá, encontrei uma nova situação.

 @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    @Column(name = "id_localizacao")
    private Integer id;

Geramos nossas tabelas no hibernate assim. Ao definir o AUTO no GenerationType deixamos a escolha do hibernate o gerenciamento da criação das sequencias para os ids. Onde mora o problema. Desta maneira ele não cria especificamente um controle de sequencias na geração dos ids para os registros, apesar de o banco de dados já estar criando os ids de forma sequencial. A diferença é muito sucinta, contudo gera problemas para o electron.

Ao tentar inserir no banco um registro com o electron, retorn:

Error
    at Query.run (C:\Users\allan\Desktop\projetos\ifpr\suap\node_modules\sequelize\lib\dialects\postgres\query.js:50:25)
    at C:\Users\allan\Desktop\projetos\ifpr\suap\node_modules\sequelize\lib\sequelize.js:315:28
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async PostgresQueryInterface.insert (C:\Users\allan\Desktop\projetos\ifpr\suap\node_modules\sequelize\lib\dialects\abstract\query-interface.js:308:21)
    at async model.save (C:\Users\allan\Desktop\projetos\ifpr\suap\node_modules\sequelize\lib\model.js:2490:35)
    at async Localizacao.create (C:\Users\allan\Desktop\projetos\ifpr\suap\node_modules\sequelize\lib\model.js:1362:12)
    at async LocalizacaoDaoImpl.inserir (C:\Users\allan\Desktop\projetos\ifpr\suap\src\dao\impl\localizacaoDaoImpl.js:107:31)
    at async LocalizacaoServico.inserir (C:\Users\allan\Desktop\projetos\ifpr\suap\src\service\LocalizacaoServico.js:24:12)
    at async inserir (C:\Users\allan\Desktop\projetos\ifpr\suap\src\controllers\LocalizacaoControle.js:21:34) {
  name: 'SequelizeDatabaseError',
  parent: error: o valor nulo na coluna "id_localizacao" da relação "tb_localizacao" viola a restrição de não-nulo
      at Parser.parseErrorMessage (C:\Users\allan\Desktop\projetos\ifpr\suap\node_modules\pg-protocol\dist\parser.js:283:98)
      at Parser.handlePacket (C:\Users\allan\Desktop\projetos\ifpr\suap\node_modules\pg-protocol\dist\parser.js:122:29)
      at Parser.parse (C:\Users\allan\Desktop\projetos\ifpr\suap\node_modules\pg-protocol\dist\parser.js:35:38)
      at Socket.<anonymous> (C:\Users\allan\Desktop\projetos\ifpr\suap\node_modules\pg-protocol\dist\index.js:11:42)
      at Socket.emit (node:events:519:28)
      at addChunk (node:internal/streams/readable:559:12)
      at readableAddChunkPushByteMode (node:internal/streams/readable:510:3)
      at Readable.push (node:internal/streams/readable:390:5)
      at TCP.onStreamRead (node:internal/stream_base_commons:191:23) {
    length: 249,
    severity: 'ERRO',
    code: '23502',
    detail: 'Registro que falhou cont├®m (null, t, sss).',
    hint: undefined,
    position: undefined,
    internalPosition: undefined,
    internalQuery: undefined,
    where: undefined,
    schema: 'public',
    table: 'tb_localizacao',
    column: 'id_localizacao',
    dataType: undefined,
    constraint: undefined,
    file: 'execMain.c',
    line: '2009',
    routine: 'ExecConstraints',
    sql: 'INSERT INTO "tb_localizacao" ("descricao","ativo") VALUES ($1,$2) RETURNING "id_localizacao","descricao","ativo";',
    parameters: [ 'sss', true ]
  },
  original: error: o valor nulo na coluna "id_localizacao" da relação "tb_localizacao" viola a restrição de não-nulo

Repare que ele não aceita o id_localizacao nulo mesmo sendo auto increment e chave primaria.

Acredito que há um equivoco do termo "AUTO" definido aqui @GeneratedValue(strategy = GenerationType.AUTO)

Definição:

  GenerationType.AUTO
Estratégia Flexível: GenerationType.AUTO permite que o provedor de persistência (como Hibernate) escolha a melhor estratégia de geração de chave com base no banco de dados usado e na configuração atual. Isso significa que o JPA tentará usar a estratégia mais apropriada para o banco de dados em questão. 

SOLUÇÃO

Após testes redefinir a o GenerationType como "IDENTIFY" possibilitou a criação de registros nas duas versões do sistema.

definição:

 GenerationType.IDENTITY é uma estratégia específica que indica que a coluna de chave primária deve ser gerada automaticamente pelo banco de dados usando um recurso de auto-incremento.

Diferença pratica: Utilizando identify

Sem identify}

Concluindo, podemos realizar alterações no Swing ? Posso inserir essa problemática na monografia ?

Complementando, fiz os testes para verificar se ficam sequenciais inserir registros pelos dois sistemas juntos, funciona normalmente.

[marceloTerencianiIFPR]

De acordo!

Todos esses registros que estão sendo feitos aqui podem ser incorporados na redação da monografia.

[OAllanFernando]

Olá, encontrei mais uma situação e até agora não consegui resolver.

Ao criarmos a herança em Estudante e Servidor a Pessoa, definimos como: @Inheritance(strategy = InheritanceType.TABLE_PER_CLASS) Faz com que sejam geradas somente as tabelas que herdam com os atributos da herdada.

Defininfo strategy = GenerationType.AUTO ocorre o problema anterior, quando altero para o IDENTIFY sequer gera o banco:

"O GenerationType.IDENTITY é usado para gerar valores de identidade diretamente no banco de dados. Isso geralmente funciona bem com tabelas de uma única classe, mas pode causar problemas em herança TABLE_PER_CLASS porque o Hibernate precisa garantir que as chaves primárias geradas sejam únicas e consistentes entre as diferentes tabelas. O TABLE_PER_CLASS pode complicar isso, pois não há um gerenciamento centralizado da geração de IDs." GPT

Tentando com GenerationType.SEQUENCE

Tentei com outras estratégias de herança até mesmo alterar as classes no sequelize, não tenho certeza se consegui todas as opções.

para teste: fix/novo_esquema_geracao_de_ids

fix/gestao-de-aluno // eletron