O que é CIDR?

 O que é CIDR?

O CIDR é uma sigla para Classes Inter-Domain Routing, e ele é considerado um método para repartir os endereços IP e para rotear.

Foi em 1993 que o CIDR foi introduzido pela Internet Engineering Task Force, e desde então esse método tem sido utilizado para substituir a arquitetura anterior que endereçava as redes.

Sua principal função era de desacelerar o crescimento das tabelas que continham os roteamentos dos roteadores na rede. Desta forma, foi possível auxiliar a desacelerar a rapidez com que os endereços IPv4 estava alcançando.

O que é um endereço IP?

Um endereço IP é formado por dois grupos de bits: o primeiro são os bits considerados mais significativos, ou seja, são os prefixos da rede. Estes identificam uma rede ou uma sub-rede.

O segundo grupo é formado pelos bits menos significativos, e eles identificam os hosts, ou seja, o responsável por especificar uma interface que é totalmente particular na rede.

A partir dessa divisão, é possível começar de uma base e então rotear o tráfego entre as redes IP e criar políticas para alocar os endereços.

Notação do CIDR

O CIDR possui uma notação que é extremamente compacta e que identifica o endereço IP e qual o seu prefixo de roteamento que está associado.

Sua notação é construída através de um endereço IP, uma barra (/) e, por último, um número decimal.

O número final será composto pela contagem dos bits 1 iniciais que está na máscara de roteamento, e esse número normalmente é conhecido como a máscara de rede.

A notação sempre representa o endereço IP de acordo com as normas e com os padrões definidos para o IPv4 e o IPv6.

Configurar um pipeline CI/CD para implantações na nuvem

 A entrega rápida de software é essencial para executar seus aplicativos na nuvem de forma eficiente. O Jenkins é um produto popular para automatizar os pipelines de integração contínua (CI) e de entrega e implantação contínuas (CD) para cargas de trabalho no Oracle Cloud.

Arquitetura

Nesta arquitetura de referência, o Jenkins é hospedado no Oracle Cloud Infrastructure para centralizar a automação de build e dimensionar a implantação usando o Oracle Cloud Infrastructure Registry e Container Engine for Kubernetes. O GitHub é usado para gerenciar código-fonte.

O GitHub fornece integração de web hook, para que o Jenkins comece a executar builds e testes automatizados após cada check-in de código. Um aplicativo Web de amostra é implantado como parte do pipeline CI/CD, que os usuários finais podem acessar no cluster do Container Engine for Kubernetes. Para simplificar o processo, o Terraform é usado para automação de infraestrutura.

O diagrama a seguir ilustra essa arquitetura de referência.

Esta arquitetura tem os seguintes componentes:

• Região

  Uma região do Oracle Cloud Infrastructure é uma área geográfica localizada que contém um ou mais data centers, chamados domínios de disponibilidade. As regiões são independentes de outras regiões e vastas distâncias podem separá-las (entre países ou mesmo continentes).

• Domínios de disponibilidade

  Os domínios de disponibilidade são centros de dados independentes e independentes em uma região. Os recursos físicos em cada domínio de disponibilidade são isolados dos recursos nos outros domínios de disponibilidade, o que fornece tolerância a falhas. Os domínios de disponibilidade não compartilham infraestrutura, como energia ou resfriamento, ou a rede de domínios de disponibilidade interna. Portanto, é improvável que uma falha em um domínio de disponibilidade afete os outros domínios de disponibilidade na região.

• Rede virtual na nuvem (VCN) e sub-redes

  O Jenkins é executado em uma instância do serviço Compute de máquina virtual (VM) implantada em um VCN que você pode segmentar em sub-redes. O Jenkins é hospedado na sub-rede pública regional A e o Container Engine for Kubernetes é implantado na sub-rede pública regional B.

• Instância de computação

  O Jenkins está implantado em uma VM da instância do serviço Compute. O cluster do Container Engine for Kubernetes também executa seus nós em instâncias do serviço Compute.

• Container Engine for Kubernetes

  O Container Engine for Kubernetes é um serviço totalmente gerenciado, escalável e altamente disponível que você pode usar para implantar seus aplicativos em contêiner na nuvem. Você especifica os recursos do serviço Compute que seus aplicativos exigem e o Container Engine for Kubernetes provisiona-os no Oracle Cloud Infrastructure em uma tenancy existente.

• Registro

  Registro é um registro gerenciado pela Oracle que permite simplificar o desenvolvimento do workflow de produção. O Registro facilita para você, como desenvolvedor, armazenar, compartilhar e gerenciar artefatos de desenvolvimento, como imagens do Docker.

• Jenkins

  O Jenkins é um servidor de automação de código-fonte aberto que permite que os desenvolvedores criem, testem e implantem software de forma confiável. O Jenkins suporta o modo mestre/agente, em que a carga de trabalho dos projetos de construção é delegada a vários nós do agente pelo mestre. Uma única instalação do Jenkins pode hospedar vários projetos ou fornecer ambientes diferentes para builds e testes.

Recomendações

Seus requisitos podem ser diferentes da arquitetura descrita aqui. Usar as recomendações a seguir como ponto inicial.

• Formas do Compute

  Esta arquitetura usa uma imagem do SO Oracle Linux com a forma VM.Standard2.1 para hospedar o servidor Jenkins e OS nós de cluster Container Engine for Kubernetes. Se o aplicativo precisar de mais memória ou núcleos, você poderá escolher uma forma diferente.

• VCN

  Ao criar uma VCN, determine o número de blocos CIDR necessários e o tamanho de cada bloco com base no número de recursos que você planeja anexar a sub-redes na VCN. Use blocos CIDR que estejam dentro do espaço de endereço IP privado padrão.

  Após criar um VCN, você pode alterar, adicionar e remover seus blocos CIDR.

  Esta arquitetura usa um VCN público para hospedar o Container Engine for Kubernetes. Você também pode usar um VCN privado. Nesse caso, use um gateway NAT para conceder ao cluster acesso pela internet pública.

• Jenkins

  Esta arquitetura implanta o Jenkins em uma instância do serviço Compute. Um nó mestre do Jenkins é usado para criar o pipeline CI/CD. Se você tiver vários pipelines para criar e executar em paralelo, poderá usar um nó do agente do Jenkins para desenvolver mais pipelines.

• Container Engine for Kubernetes

  Esta arquitetura implanta o cluster do Container Engine for Kubernetes. OS nós de trabalho são implantados em um SO Oracle Linux do VM.Standard2.1. Essa arquitetura usa três nós de trabalho no cluster, mas você pode criar até 1000 nós em cada cluster.

• Registro

  Esta arquitetura implanta o Registro como um registro Docker privado para uso interno. As imagens do Docker são enviadas e extraídas do Registro. Você também pode usar o Registro como um registro público do Docker, permitindo que qualquer usuário com acesso à Internet e conhecimento do URL apropriado extraia imagens de repositórios públicos no Oracle Cloud.

Considerações

• Escalabilidade

  Você pode ampliar seu aplicativo atualizando o número de nós de trabalho no cluster do Container Engine for Kubernetes, dependendo da carga. Você também pode ampliar, reduzindo o número de nós de trabalho no cluster. Ao criar um serviço no cluster, você pode criar um balanceador de carga para distribuir tráfego entre os nós designados a esse serviço. Para o Jenkins, você pode usar o nó mestre do Jenkins para criar mais agentes para vários pipelines.

• Disponibilidade do aplicativo

  Os domínios de falha fornecem a melhor resiliência dentro de um único domínio de disponibilidade. Você pode implantar instâncias do serviço Compute que executam as mesmas tarefas em vários domínios de disponibilidade. Esse design remove um único ponto de falha introduzindo redundância.

• Capacidade de gerenciamento

  Essa arquitetura usa um exemplo de aplicativo Web hospedado no GitHub para controle de origem. O registro é usado no pipeline de build para armazenar a imagem de build do Docker para o aplicativo.

• Segurança

  Use políticas para restringir quem pode acessar os recursos do Oracle Cloud Infrastructure que sua empresa tem e como.

  O Container Engine for Kubernetes é integrado ao Oracle Cloud Infrastructure Identity and Access Management (IAM), que fornece autenticação fácil com a funcionalidade de identidade nativa do Oracle Cloud Infrastructure.

Implantar

O código necessário para implantar essa arquitetura de referência está disponível no GitHub. Você pode extrair o código para o Oracle Cloud Infrastructure Resource Manager com um único clique, criar a pilha e implantá-la. Como alternativa, faça download do código do GitHub para seu computador, personalize-o e implante a arquitetura usando a CLI do Terraform.

• Implante usando o Oracle Cloud Infrastructure Resource Manager:
  1. Clique em 

     Se você ainda não tiver efetuado sign-in, informe as credenciais da tenancy e do usuário.

  2. Analise e aceite os termos e as condições.
  3. Selecione a região onde você deseja disponibilizar a pilha.
  4. Siga os prompts na tela e as instruções para criar a pilha.
  5. Depois de criar a pilha, clique em Ações do Terraform e selecione Plano.
  6. Aguarda até que o job seja concluído e revisa o plano.

     Para fazer alterações, retorne à página Detalhes da Pilha, clique em Editar Pilha e faça as alterações necessárias. Em seguida, execute a ação do Plano novamente.

  7. Se não forem necessárias mais alterações, retorne à página Detalhes da Pilha, clique em Ações do Terraform e selecione Aplicar.
• Implante usando a CLI do Terraform:
  1. Vá para o GitHub.
  2. Faça download ou clone o código no computador local.
  3. Siga as instruções em README.md.

Criando endpoints pensando em TDD - desenvolvimento de softwares guiado por Testes

 TDD é a sigla para Test Driven Development, que em português significa Desenvolvimento Orientado por Testes. Esse é um método de desenvolvimento muito comum atualmente. Ele se baseia na aplicação de pequenos ciclos de repetições. Em cada um deles, um teste é aplicado.

Basicamente é o que o nome diz, o desenvolvimento de softwares guiado por Testes. Vale dizer que isso começou com o Kent Beck, que foi o criador do TDD.

Fiz esse desenho para ilustrar melhor sobre:

E a ideia é exatamente essa mesmo, você escrever primeiro o teste unitário no seu código fonte, antes mesmo de escrever a funcionalidade em si. Ou seja:

1- Escreva um teste que vai falhar (exatamente porque a funcionalidade ainda nem existe).

2- Escreva a funcionalidade em si, com o código que vai fazê-la funcionar

3- Refatore o seu código, eliminando redundâncias, deixando ele mais elegante e etc…

Hands on

Chega de resumir e vamos colocar a mão na massa. Bom, vou criar um endpoint simples com Spring que o único objetivo é retornar uma lista e outro método em uma service que o objetivo é saber se uma idade que será passada como parâmetro é maior de idade ou não.

Vamos ao nosso primeiro endpoint, lembrando que primeiro vamos criar uma classe chamada Usuário, ela ainda não faz parte da nossa funcionalidade em si, mas será uma classe importante:

import lombok.Builder;

import lombok.Data;

@Data

@Builder

public class Usuario {

    private String nome;

    private String email;

    private int idade;

}

Vamos adicionar ao nosso projeto essas duas dependências:

<!--junit-->

<dependency>

               <groupId>junit</groupId>

                                            <artifactId>junit</artifactId>

                              </dependency>

                              <!--mockito-->

                              <dependency>

                                            <groupId>org.mockito</groupId>

                                            <artifactId>mockito-core</artifactId>

</dependency>

Feito isso, vamos criar a nossa UsuarioController da seguinte forma:

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.Arrays;
import java.util.List;

@RestController
@RequestMapping("usuario")
public class UsuarioController {
       
}

Repare que ela está vazia, sem implementação alguma e de fato essa é a ideia!
Agora vamos criar o teste da nossa controller:

import org.junit.jupiter.api.Test;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.test.autoconfigure.web.servlet.WebMvcTest;
import org.springframework.test.web.servlet.MockMvc;
import org.springframework.test.web.servlet.request.MockMvcRequestBuilders;
import org.springframework.test.web.servlet.result.MockMvcResultHandlers;
import org.springframework.test.web.servlet.result.MockMvcResultMatchers;

@WebMvcTest(UsuarioController.class)
public class UsuarioControllerTests {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void testarListaUsuario() throws Exception {
        this.mockMvc.perform(MockMvcRequestBuilders.get("/usuario")) //teste para acessar o endpoint
                .andDo(MockMvcResultHandlers.print()) // print do resultado do teste
                .andExpect(MockMvcResultMatchers.jsonPath("$").isArray()); // verificando se o endpoint retorna um array
    }

Repare que nós já escrevemos o teste do que o nosso endpoint tem que fazer (retornar uma lista), porém ainda nem criamos a funcionalidade em si, por isso quando rodamos o teste, vai dar erro mesmo:





Perfeito! Agora que já sabemos o que o nosso endpoint tem que fazer e inclusive testamos isso, vamos criar de fato a funcionalidade:
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

@RestController
@RequestMapping("usuario")
public class UsuarioController {

    @GetMapping
    public List<Usuario> listaUsuario() {
        List<Usuario> listaUsuarios = new ArrayList<>();
        listaUsuarios.add(new Usuario("Nataniel", "nataniel.paiva@gmail.com", 29));
        return listaUsuarios;
    }

}
Esse é o passo 2, como a funcionalidade está criada, agora podemos rodar de fato o teste trazendo um resultado correto:
Agora, vamos ao passo 3, que é o de refatorar o código do nosso endpoint:
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;

@RestController
@RequestMapping("usuario")
public class UsuarioController {

    @GetMapping
    public List<Usuario> listaUsuario() {
        return Arrays.asList(
                Usuario
                .builder()
                .nome("Nataniel")
                .email("nataniel.paiva@gmail.com")
                .idade(29).build());
    }

}
Agora no passo 3 podemos deixar o nosso código mais elegante! E a ideia do TDD é exatamente essa, você vai construindo as suas funcionalidades guiado pelos testes.
Agora vamos para a nossa segunda funcionalidade. Vamos precisar de uma Service com um método para validar se uma idade passada como parâmetro é maior de idade ou não.
Criamos apenas a “casca” da nossa service:
import org.springframework.stereotype.Service;

@Service
public class UsuarioService {
  
  public boolean verificaMaiorIdade(int idade){
        return true;
    }

}
Até criei o método, mas repare que ele apenas tem o retorno para não ter erro de compilação. Agora vamos para o nosso teste:
import org.junit.Assert;
import org.junit.Test;
import org.junit.runner.RunWith;
import org.mockito.InjectMocks;
import org.mockito.junit.MockitoJUnitRunner;

@RunWith(MockitoJUnitRunner.class)
public class UsuarioServiceTests {

    @InjectMocks
    public UsuarioService usuarioService;

    @Test
    public void verificaMaiorIdade() {
        Boolean teste = usuarioService.verificaMaiorIdade(18);
        Assert.assertTrue(teste);
    }

    @Test
    public void verificaMenorIdade() {
        boolean teste = usuarioService.verificaMaiorIdade(17);
        Assert.assertFalse(teste);
    }

}
Repare que um dos testes escritos vai trazer um falso positivo, porém estamos testando o que queremos de fato na funcionalidade. Então vamos criar a funcionalidade de fato.
import org.springframework.stereotype.Service;

@Service
public class UsuarioService {

    public boolean verificaMaiorIdade(int idade){
        boolean retorno = false;
        if(idade >= 18){
            retorno = true;
        }
        return retorno;
    }

}
Repare que agora os dois testes que fizemos irão passar. Agora vamos tentar melhorar o nosso código:
import org.springframework.stereotype.Service;

@Service
public class UsuarioService {

    public boolean verificaMaiorIdade(int idade){
        return idade >= 18;
    }

}

Calculadora de Imposto de Renda

 Uma API REST com Spring Boot para calcular imposto de renda entrando com o valor do salário e número de dependentes.

- API Rest esta documentada com a ferramenta Swagger.

- Implementados Testes unitários mockito e JUnit.

- Banco de dados Mysql.

- Front-end em Angular 9 

- Publicada no Heroku

Anotações de Mapeamento do Hibernate

 

@AccessType

A anotação @AccessType está obsoleta. Você deve usar o JPA @Access ou a anotação @AttributeAccessor nativa do Hibernate.

@Any

A anotação @Any é usada para definir a associação any-to-one , que pode apontar para um dos vários tipos de entidade.

@AnyMetaDef

A anotação @AnyMetaDef é usada para fornecer metadados sobre um mapeamento @ManyToAny ou @ManyToAny .

@AnyMetaDefs

A anotação @AnyMetaDefs é usada para agrupar várias anotações @AnyMetaDef .

@AttributeAccessor

A anotação @AttributeAccessor é usada para especificar um PropertyAccessStrategy customizado. Isso só deve ser usado para nomear um PropertyAccessStrategy personalizado. Para o tipo de acesso de propriedade / campo, a anotação JPA @Access deve ser preferida. No entanto, se essa anotação for usada com valor = “propriedade” ou valor = “campo”, ela funcionará exatamente como o uso correspondente da anotação JPA @Access .

@BatchSize

A anotação @BatchSize é usada para especificar o tamanho do lote que carrega as entradas de uma coleção lenta.

@Cache

A anotação @Cache é usada para especificar o CacheConcurrencyStrategy de uma entidade raiz ou uma coleção.

@Cascade

A anotação @Cascade é usada para aplicar as estratégias CascadeType específicas do Hibernate (por exemplo, CascadeType.LOCK, CascadeType.SAVE_UPDATE, CascadeType.REPLICATE) em uma determinada associação.

Para o JPA em cascata, prefiro usar o javax.persistence.CascadeType. Ao combinar as estratégias JPA e Hibernate CascadeType , o Hibernate mesclará os dois conjuntos de cascatas.

@Check

A anotação @Check é usada para especificar uma restrição SQL SQL arbitrária que pode ser definida no nível de classe.

@CollectionId

A anotação @CollectionId é usada para especificar uma coluna identificadora para uma coleção idbag .

@CollectionType

A anotação @CollectionType é usada para especificar um tipo de coleção customizado.

A coleção também pode nomear um @Type, que define o tipo de hibernação dos elementos da coleção.

@ColumnDefault

A anotação @ColumnDefault é usada para especificar o valor DEFAULT DDL a ser aplicado ao usar o gerador de esquema automatizado. O mesmo comportamento pode ser obtido usando o atributo definition da anotação JPA @Column.

@Columns

A anotação @Columns é usada para agrupar várias anotações JPA @Column .

@ColumnTransformer

A anotação @ColumnTransformer é usada para customizar como um determinado valor de coluna é lido ou gravado no banco de dados.

@ColumnTransformers

A anotação @ColumnTransformers é usada para agrupar várias anotações @ColumnTransformer .

@CreationTimestamp

A anotação @CreationTimestamp é utilizada para especificar que o tipo temporal atualmente anotado deve ser inicializado com o valor de registro de data e hora da JVM atual.

@DiscriminatorFormula

A anotação @DiscriminatorFormula é usada para especificar um @Formula do Hibernate para resolver o valor do discriminador de herança.

@DiscriminatorOptions

A anotação @DiscriminatorOptions é usada para fornecer a força e inserir as propriedades do Discriminador.

@DynamicInsert

A anotação @DynamicInsert é usada para especificar que a instrução SQL INSERT deve ser gerada sempre que uma entidade for persistida.

Por padrão, o Hibernate usa uma instrução INSERT em cache que define todas as colunas da tabela. Quando a entidade é anotada com a anotação @DynamicInsert, o PreparedStatement incluirá apenas as colunas não nulas.

@DynamicUpdate

A anotação @DynamicUpdate é usada para especificar que a instrução SQL UPDATE deve ser gerada sempre que uma entidade é modificada.

Por padrão, o Hibernate usa uma instrução UPDATE armazenada em cache que define todas as colunas da tabela. Quando a entidade é anotada com a anotação @DynamicUpdate , o PreparedStatement incluirá apenas as colunas cujos valores foram alterados.

@Entity

A anotação @Entity está obsoleta. Use a anotação JPA @Entity .

@Fetch

A anotação @Fetch é usada para especificar o FetchMode específico do Hibernate (por exemplo, JOIN, SELECT, SUBSELECT) usado para a associação atualmente anotada.

@FetchProfile

A anotação @FetchProfile é usada para especificar um perfil de busca customizado, semelhante a um Gráfico de Entidade JPA.

@FetchProfile.FetchOverride

A anotação @FetchProfile.FetchOverride é usada em conjunto com a anotação @FetchProfile e é usada para substituir a estratégia de busca de uma associação de entidade particular.

@FetchProfiles

A anotação @FetchProfiles é usada para agrupar várias anotações @FetchProfile.

@Filter

A anotação @Filter é usada para adicionar filtros a uma entidade ou a entidade de destino de uma coleção.

@FilterDef

A anotação @FilterDef é usada para especificar uma definição @Filter (nome, condição padrão e tipos de parâmetro, se houver).

@FilterDefs

A anotação @FilterDefs é usada para agrupar várias anotações @FilterDef .

@FilterJoinTable

A anotação @FilterJoinTable é usada para adicionar recursos @Filter a uma coleção de tabelas de junção.

@FilterJoinTables

A anotação @FilterJoinTables é usada para agrupar várias anotações @FilterJoinTable .

@Filters

A anotação @Filters é usada para agrupar várias anotações @Filter .

@ForeignKey

A anotação @ForeignKey está obsoleta. Use a anotação JPA 2.1 @ForeignKey .

@Formula

A anotação @Formula é usada para especificar um fragmento SQL que é executado para preencher um determinado atributo de entidade.

@Generated

A anotação @Generated é usada para especificar que o atributo da entidade anotada atualmente é gerado pelo banco de dados.

@GeneratorType

A anotação @GeneratorType é usada para fornecer um ValueGenerator e um GenerationTime para o atributo gerado atualmente anotado.

@GenericGenerator

A anotação @GenericGenerator pode ser usada para configurar qualquer gerador de identificadores do Hibernate.

@GenericGenerators

A anotação @GenericGenerators é usada para agrupar várias anotações do @GenericGenerator .

@Immutable

A anotação @Immutable é usada para especificar que a entidade, atributo ou coleção anotada é imutável.

@Index

A anotação @Index está obsoleta. Use a anotação JPA @Index .

@IndexColumn

A anotação @IndexColumn está obsoleta. Use a anotação JPA @OrderColumn .

@JoinColumnOrFormula

A anotação @JoinColumnOrFormula é usada para especificar que a associação de entidades é resolvida através de uma junção FOREIGN KEY (por exemplo, @JoinColumn ) ou usando o resultado de uma dada fórmula SQL (por exemplo, @JoinFormula ).

@JoinColumnsOrFormulas

A anotação @JoinColumnsOrFormulas é usada para agrupar várias anotações @JoinColumnOrFormula .

@JoinFormula

A anotação @JoinFormula é usada como um substituto para @JoinColumn quando a associação não possui uma coluna FOREIGN KEY dedicada.

@LazyCollection

A anotação @LazyCollection é usada para especificar o comportamento de busca preguiçosa de uma determinada coleção.

Os valores TRUE e FALSE estão obsoletos, pois você deve usar o atributo JPA FetchType da coleção @ElementCollection, @OneToMany ou @ManyToMany .

@LazyGroup

A anotação @LazyGroup é usada para especificar que um atributo de entidade deve ser buscado junto com todos os outros atributos pertencentes ao mesmo grupo.

Para carregar os atributos da entidade preguiçosamente, o aprimoramento do bytecode é necessário. Por padrão, todos os atributos de não coleta são carregados em um grupo chamado “DEFAULT”.

Esta anotação permite definir diferentes grupos de atributos a serem inicializados juntos quando acessam um atributo no grupo.

@LazyToOne

A anotação @LazyToOne é usada para especificar as opções de preguiça, representadas por LazyToOneOption , disponíveis para uma associação @OneToOne ou @OneToOne .

@ListIndexBase

A anotação @ListIndexBase é usada para especificar o valor inicial de um índice de lista, conforme armazenado no banco de dados.

Por padrão, os índices de lista são armazenados a partir de zero. Isso geralmente é usado em conjunto com @OrderColumn .

@Loader

A anotação @Loader é usada para substituir a consulta SELECT padrão usada para carregar um carregamento de entidade.

@ManyToAny

A anotação @ManyToAny é usada para especificar uma associação muitos para um quando o tipo de destino é resolvido dinamicamente.

@MapKeyType

A anotação @MapKeyType é usada para especificar o tipo de chave do mapa.

@MetaValue

A anotação @MetaValue é usada pela anotação @AnyMetaDef para especificar a associação entre um determinado valor de discriminador e um tipo de entidade.

@NamedNativeQueries

A anotação @NamedNativeQuery estende o JPA @NamedNativeQuery com recursos específicos do Hibernate.

@NamedQueries

A anotação @NamedQueries é usada para agrupar várias anotações @NamedQuery .

@NamedQuery

A anotação @NamedQuery estende o JPA @NamedQuery com recursos específicos do Hibernate.

@Nationalized

A anotação @Nationalized é usada para especificar que o atributo anotado atualmente é um tipo de caractere (por exemplo, String, Character, Clob) que é armazenado em um tipo de coluna nacionalizada (NVARCHAR, NCHAR, NCLOB).

@NaturalId

A anotação @NaturalId é usada para especificar que o atributo atualmente anotado faz parte do ID natural da entidade.

@NaturalIdCache

A anotação @NaturalIdCache é usada para especificar que os valores de id naturais associados à entidade anotada devem ser armazenados no cache de segundo nível.

@NotFound

A anotação @NotFound é usada para especificar a estratégia NotFoundAction para quando um elemento não é encontrado em uma determinada associação.

@OnDelete

A anotação @OnDelete é usada para especificar a estratégia de exclusão empregada pela coleção atualmente anotada, matriz ou subclasses unidas. Essa anotação é usada pela ferramenta de geração automática de esquema para gerar a diretiva em cascata DDL FOREIGN KEY apropriada.

@OptimisticLock

A anotação @OptimisticLock é usada para especificar se o atributo atualmente anotado acionará um incremento de versão de entidade ao ser modificado.

@OptimisticLocking

A anotação @OptimisticLocking é usada para especificar a estratégia de bloqueio otimista de entidade atualmente anotada.

@OrderBy

A anotação @OrderBy é usada para especificar uma diretiva de ordenação SQL para classificar a coleta atualmente anotada.

Ele difere da anotação JPA @OrderBy porque a anotação JPA espera um fragmento de ordem JPQL, não uma diretiva SQL.

@ParamDef

A anotação @ParamDef é usada em conjunto com @FilterDef para que o Filtro de Hibernação possa ser personalizado com valores de parâmetros fornecidos pelo tempo de execução.

@Parameter

A anotação @Parameter é um parâmetro genérico (basicamente uma combinação de chave / valor) usado para parametrizar outras anotações, como @CollectionType , @GenericGenerator , @Type e @TypeDef .

@Parent

A anotação @Parent é usada para especificar que o atributo incorporável atualmente anotado faz referência à entidade proprietária.

@Persister

A anotação @Persister é usada para especificar uma entidade personalizada ou uma persistência de coleta.

Para entidades, o persistero personalizado deve implementar a interface EntityPersister .

@Polymorphism

A anotação @Polymorphism é usada para definir o PolymorphismType O Hibernate será aplicado às hierarquias de entidade.

@Proxy

A anotação @Proxy é usada para especificar uma implementação de proxy personalizada para a entidade atualmente anotada.

@RowId

A anotação @RowId é usada para especificar a coluna do banco de dados usada como uma pseudocoluna ROWID. Por exemplo, o Oracle define a pseudocoluna ROWID como algo que fornece o endereço de cada linha da tabela.

@SelectBeforeUpdate

A anotação @SelectBeforeUpdate é usada para especificar que o estado da entidade anotada atualmente seja selecionado no banco de dados ao determinar se deve ser executada uma atualização quando a entidade desanexada for reconectada.

@Sort

A anotação @Sort está obsoleta. Use as anotações @SortComparator ou @SortNatural específicas do Hibernate.

@SortComparator

A anotação @SortComparator é usada para especificar um Comparador para classificar o Conjunto / Mapa na memória.

@SortNatural

A anotação @SortNatural é usada para especificar que o Set / Map deve ser classificado usando a ordenação natural.

@Source

A anotação @Source é usada em conjunto com um atributo de entidade de data @Version hora @Version indicando o SourceType do valor de registro de data e hora.

@SQLDelete

A anotação @SQLDelete é usada para especificar uma instrução SQL DELETE personalizada para a entidade ou coleção atualmente anotada.

@SQLDeleteAll

A anotação @SQLDeleteAll é usada para especificar uma instrução SQL DELETE personalizada ao remover todos os elementos da coleção atualmente anotada.

@SqlFragmentAlias

A anotação @SqlFragmentAlias é usada para especificar um alias para um @Filter do Hibernate.

O alias (por exemplo, myAlias) pode ser usado na cláusula de condição @Filter usando o alocador de espaço {alias} (por exemplo, {myAlias}).

@SQLInsert

A anotação @SQLInsert é usada para especificar uma instrução SQL INSERT personalizada para a entidade ou coleção atualmente anotada.

@SQLUpdate

A anotação @SQLUpdate é usada para especificar uma instrução SQL UPDATE personalizada para a entidade ou coleção atualmente anotada.

@Subselect

A anotação @Subselect é usada para especificar uma entidade imutável e somente leitura usando uma instrução SQL SELECT personalizada.

@Synchronize

A anotação @Synchronize é geralmente usada em conjunto com a anotação @Subselect para especificar a lista de tabelas de banco de dados usada pela consulta SQL @Subselect .

@Table

A anotação @Table é usada para especificar informações adicionais para uma anotação JPA @Table, como as instruções customizadas INSERT, UPDATE ou DELETE ou um FetchMode específico.

@Tables

A anotação @Tables é usada para agrupar várias anotações @Table .

@Target

A anotação @Target é usada para especificar uma implementação de destino explícita quando a associação atualmente anotada estiver usando um tipo de interface.

@Tuplizer

A anotação @Tuplizer é usada para especificar um tuplizador personalizado para a entidade atualmente anotada ou incorporável.

@Tuplizers

A anotação @Tuplizers é usada para agrupar várias anotações do @Tuplizer.

@Type

A anotação @Type é usada para especificar o @Type do Hibernate usado pelo atributo básico atualmente anotado.

@TypeDef

A anotação @TypeDef é usada para especificar uma definição @Type , que pode ser reutilizada posteriormente para vários mapeamentos básicos de atributos.

@TypeDefs

A anotação @TypeDefs é usada para agrupar várias anotações @TypeDef .

@UpdateTimestamp A anotação @UpdateTimestamp é usada para especificar que o atributo de registro de data e hora anotado atualmente deve ser atualizado com o registro de data / hora da JVM atual sempre que a entidade proprietária for modificada.

@ValueGenerationType

A anotação @ValueGenerationType é usada para especificar que o tipo de anotação atual deve ser usado como um tipo de anotação de gerador.

@Where

A anotação @Where é usada para especificar uma cláusula SQL WHERE customizada usada ao buscar uma entidade ou uma coleção.

@WhereJoinTable

A anotação @WhereJoinTable é usada para especificar uma cláusula SQL WHERE customizada usada ao buscar uma tabela de coleta de junção.