Translate
Mostrando las entradas con la etiqueta jakarta. Mostrar todas las entradas
Mostrando las entradas con la etiqueta jakarta. Mostrar todas las entradas
viernes, 13 de diciembre de 2019
Introducción a Jakarta NoSQL
EE4J no se detiene y ha aprobado el proyecto Jakarta NoSQL es una especificación en Jakarta EE para ayudar a los desarrolladores a crear aplicaciones de nivel empresarial utilizando tecnologías Java y NoSQL. JNoSQL es la implementación de referencia de Jakarta NoSQL, que proporciona un conjunto de APIs y una implementación estándar para una serie de bases de datos NoSQL, como Cassandra, MongoDB, Neo4J, CouchDB y OrientDB, entre otras.
Jakarta NoSQL consiste en una capa de comunicación (Diana), que extrae un conjunto de APIs diseñadas para definir la comunicación con las bases de datos NoSQL. Contiene cuatro módulos de acuerdo con cada tipo de base de datos NoSQL: clave-valor, familia de columnas, documento y grafo; y una capa de mapeo (Artemis), que proporciona una serie de APIs para ayudar a los desarrolladores a integrar aplicaciones Java con bases de datos NoSQL. La capa de mapeo se basa en anotaciones y utiliza tecnologías como CDI y Bean Validation, lo que facilita el uso de los desarrolladores. Es posible comparar la capa de mapeo con JPA / Hibernate en el mundo tradicional RDBMS.
La definición de una entidad es relativamente similar a JPA. Básicamente usa @Entity, @Id, @Column y así sucesivamente:
@Entity
public class Person {
@Id
private long id;
@Column
private String name;
@Column
private List phones;
}
Los repositorios se parecen a los repositorios de Spring Data, donde se extiende un Repositorio <T, ID>:
public interface PersonRepository extends Repository {
List<Person> findByName(String name);
Stream<Person> findByPhones(String phone);
}
Sin embargo, a partir de este momento, las cosas cambian, ya que las dependencias de Maven cambian de acuerdo con el tipo de base de datos NoSQL que se usa, así como la configuración y cómo inyectamos el repositorio en nuestros servicios.
Veamos 2 ejemplos, uno utilizando una base orientada a columna y otra documental. Importamos librerías :
<dependency>
<groupId>org.jnosql.artemis</groupId>
<artifactId>artemis-column</artifactId>
<version>0.0.9</version>
</dependency>
<dependency>
<groupId>org.jnosql.diana</groupId>
<artifactId>cassandra-driver</artifactId>
<version>0.0.9</version>
</dependency>
Veamos el manager de nuestra base orientada a columna :
@ApplicationScoped
public class ColumnFamilyManagerProducer {
private static final String KEY_SPACE = "developers";
private ColumnConfiguration<> cassandraConfiguration;
private ColumnFamilyManagerFactory managerFactory;
@PostConstruct
public void init() {
cassandraConfiguration = new CassandraConfiguration();
managerFactory = cassandraConfiguration.get();
}
@Produces
public ColumnFamilyManager getManagerCassandra() {
return managerFactory.get(KEY_SPACE);
}
}
Y finalmente, un ejemplo de cómo ejecutar algunas inserciones / consultas:
Person person = Person.builder()
.withPhones(Arrays.asList("234", "432"))
.withName("Name")
.withId(id)
.build();
//using ColumnTemplate
ColumnTemplate columnTemplate = container.select(CassandraTemplate.class).get();
Person saved = columnTemplate.insert(PERSON);
System.out.println("Person saved" + saved);
ColumnQuery query = select().from("Person").where(eq(Column.of("id", 1L))).build();
Optional<Person> person = columnTemplate.singleResult(query);
System.out.println("Entity found: " + person);
//using PersonRepository
PersonRepository repository = container.select(PersonRepository.class).select(ofColumn()).get();
Person saved = repository.save(PERSON);
System.out.println("Person saved" + saved);
Optional<Person> person = repository.findById(1L);
System.out.println("Entity found: " + person);
Veamos un ejemplo con una base documental, primero las dependencias:
<dependency>
<groupId>org.jnosql.artemis</groupId>
<artifactId>artemis-document</artifactId>
<version>0.0.9</version>
</dependency>
<dependency>
<groupId>org.jnosql.diana</groupId>
<artifactId>mongodb-driver</artifactId>
<version>0.0.9</version>
</dependency>
Luego el manager :
@ApplicationScoped
public class DocumentCollectionManagerProducer {
private static final String COLLECTION = "developers";
private DocumentConfiguration configuration;
private DocumentCollectionManagerFactory managerFactory;
@PostConstruct
public void init() {
configuration = new MongoDBDocumentConfiguration();
Map<String, Object> settings = Collections.singletonMap("mongodb-server-host-1", "localhost:27017");
managerFactory = configuration.get(Settings.of(settings));
}
@Produces
public DocumentCollectionManager getManager() {
return managerFactory.get(COLLECTION);
}
}
y usamos el manager :
Person person = Person.builder()
.withPhones(Arrays.asList("234", "432"))
.withName("Name")
.withId(id)
.build();
//using DocumentTemplate
DocumentTemplate documentTemplate = container.select(DocumentTemplate.class).get();
Person saved = documentTemplate.insert(person);
System.out.println("Person saved" + saved);
DocumentQuery query = select().from("Person")
.where(eq(Document.of("_id", id))).build();
Optional<Person> personOptional = documentTemplate.singleResult(query);
System.out.println("Entity found: " + personOptional);
//using PersonRepository
PersonRepository repository = container.select(PersonRepository.class)
.select(ofDocument()).get();
repository.save(person);
List<Person> people = repository.findByName("Name");
System.out.println("Entity found: " + people);
repository.findByPhones("234").forEach(System.out::println);
Y listo!
Ustedes pensaran que feo tener diferentes modos de guardar y recuperar datos de nuestros almacenes de datos sql pero tengamos en cuenta que es el único camino para aprovechar al máximo sus particularidades y normalmente elegimos estas bases por sus particularidades.
Dejo link: https://github.com/eclipse-ee4j/nosql
Suscribirse a:
Entradas (Atom)