Introducing Ottoman v2.0: An ODM for Node.js & Couchbase

En nombre del equipo de CouchbaseEstoy encantado de anunciar la disponibilidad general de Ottoman 2.0.

Otomano es una librería Object Document Mapper (ODM) para Couchbase y Node.js que mapea documentos JSON almacenados en Couchbase a objetos JavaScript nativos. Ottoman funciona con el SDK de Couchbase Node.js y es compatible con JavaScript y TypeScript.

Una aplicación web típica consta de un front-end, un back-end y un almacén de datos. Ottoman es un componente de tu backend que actúa como enlace entre el framework de la aplicación cliente y Couchbasetu almacén de datos.

Por qué necesita un ODM para Couchbase

La mayoría de las aplicaciones cliente-servidor necesitan algún tipo de abstracción que permita gestionar el acceso a los datos. El término "acceso a datos" puede sonar trivial para algunos y confundirse rápidamente con operaciones básicas CRUD (crear, leer, actualizar y borrar), pero eso no es del todo exacto.

La gestión de datos en una aplicación moderna va desde el simple acceso a los datos, hasta la transformación, validación y modelización de los datos que se adapte a las necesidades de los distintos usuarios y sistemas. Puede que decida optar por una base de datos políglota y sus correspondientes patrones de acceso a los datos, pero en cualquier caso, la calidad de sus datos debe ser limpia y legítima.

Si eres un usuario que viene de una base de datos relacional, puede que ya estés familiarizado con los esquemas y restricciones que vienen de forma nativa con estas bases de datos y que aseguran la integridad de los datos. Sin embargo, esto puede ser un reto cuando se utiliza una base de datos NoSQL como Couchbase, donde la estructura de los datos es fluida.

En tal caso, es posible que sientas que tienes que construir tu propia biblioteca de "gestor de esquemas" que necesita definir esquemas, construir modelos de datos, validar datos, garantizar restricciones, gestionar relaciones y mucho más. Construir algo así uno mismo puede escapársele rápidamente de las manos. Este tipo de sistemas no sólo son difíciles de mantener y escalar, sino que pueden acabar siendo propensos a errores y consumir mucho tiempo, lo que se traduce en retrasos en la entrega y en la calidad de los datos.

Encontrar una biblioteca que ya abarque todo lo anterior es esencial. Aquí es donde un ODM como Ottoman hace que todo parezca fácil.

Ottoman facilita el desarrollo en Node.js

Para entender cómo Ottoman ayuda a sus equipos de desarrollo, echemos un vistazo más de cerca a las nuevas características de Ottoman 2.0.

Los ejemplos de este blog se basan en el viaje-muestra y sólo tienen fines ilustrativos. Además, este blog presupone que el usuario tiene conocimientos básicos de ámbitos y colecciones en Couchbase 7.0.

Esquemas y modelos de datos

Documentos JSON en Servidor Couchbase 7.0 pueden organizarse en ámbitos y colecciones, lo que ofrece a los usuarios finales la posibilidad de crear aplicaciones basadas en microservicios multiusuario.

En Ottoman, el modelo de datos indica en qué ámbito y colección se almacena el documento y proporciona numerosos métodos para acceder a esos documentos. Los esquemas, por su parte, definen la forma del documento.

Veamos más de cerca esquemas y modelos con un ejemplo sencillo.

El siguiente ejemplo de código define un esquema de línea aérea que tiene cinco campos con algunas restricciones y valores por defecto especificados. Por ejemplo, el campo país sólo puede tener los valores Estados Unidos y Canadá y es necesario al crear un documento. La capacidad, por su parte, es un número que puede tener un valor máximo de 1000si se especifica.

Por defecto, los esquemas son "estrictos", lo que significa que Ottoman tiene instrucciones de garantizar que el documento guardado en la base de datos debe ajustarse a la estructura de esquema definida, y cualquier campo adicional definido se ignora al guardarlo. Esta opción estricta puede anularse utilización de las opciones del esquema.

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default: 'airline' },
  name: { type: String, required: true  },
  country: { type: String, required: true, enum: ['United States', 'Canada']  },
  capacity: { type: Number, max: 1000 } 
})

const airlineSchema = nuevo Esquema({

id: { tipo: Cadena },

tipo: { tipo: Cadena, obligatorio: verdadero, por defecto: aerolínea },

nombre: { tipo: Cadena, obligatorio: verdadero },

país: { tipo: Cadena, obligatorio: verdadero, enum: [Estados Unidos, Canadá] },

capacidad: { tipo: Número, max: 1000 }

})

Para utilizar el airlineSchematienes que crear un modelo:

const airlineModel = model('Airline', airlineSchema, { scopeName: '_default' })

1	const aerolíneaModelo = modelo(Aerolínea, airlineSchema, { scopeName: por defecto })

El primer parámetro es el nombre del modelo, que también es el nombre de la colección si no se sobrescribe con opciones de modelo.

Los documentos otomanos representan una correspondencia uno a uno con los documentos almacenados en Couchbase. Cada documento es una instancia de su modelo.

const airlineDocument = new airlineModel({
  id: "10",
  type: "airline",
  name: "MILE-AIR",
  country:"United States"
})

const airlineDocument = nuevo aerolíneaModelo({

id: "10",

tipo: "aerolínea",

nombre: "MILE-AIR",

país:"Estados Unidos"

})

Llamando al guardar en el aerolíneaModelo, acabas creando un documento dentro del Línea aérea colección situada bajo el Por defecto de su base de datos Couchbase.

Marcas de tiempo

La opción de esquema de fecha y hora indica a Ottoman que añada automáticamente un createdAt y updatedAt datetime con un valor por defecto de fecha y hora actuales cada vez que se crea un documento. Cada vez que se actualiza el documento, el updatedAt también se actualiza.

A continuación se muestra un ejemplo de adición de una opción de marca de tiempo al esquema de aerolíneas:

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default: 'airline' },
  name: { type: String, required: true },
  country: { type: String, required: true, enum: ['United States', 'Canada'] },
  capacity: { type: Number, max: 1000 } 
}, { timestamps: true })

const airlineSchema = nuevo Esquema({

id: { tipo: Cadena },

tipo: { tipo: Cadena, obligatorio: verdadero, por defecto: aerolínea },

nombre: { tipo: Cadena, obligatorio: verdadero },

país: { tipo: Cadena, obligatorio: verdadero, enum: [Estados Unidos, Canadá] },

capacidad: { tipo: Número, max: 1000 }

}, { marcas de tiempo: verdadero })

Este paso (arriba) básicamente amplía el esquema para añadir implícitamente dos nuevos campos. También puede llamarlos explícitamente si es necesario y anular sus nombres, como se muestra a continuación:

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default: 'airline' },
  name: { type: String, required: true },
  country: { type: String, required: true, enum: ['United States', 'Canada']  },
  capacity: { type: Number, max: 1000 } ,
  created_at: { type: Date, default: new Date() },
  updated_at: { type: Date, default: new Date() }
}, { timestamps: { createdAt: 'created_at', updatedAt: 'updated_at' }})

const airlineSchema = nuevo Esquema({

id: { tipo: Cadena },

tipo: { tipo: Cadena, obligatorio: verdadero, por defecto: aerolínea },

nombre: { tipo: Cadena, obligatorio: verdadero },

país: { tipo: Cadena, obligatorio: verdadero, enum: [Estados Unidos, Canadá] },

capacidad: { tipo: Número, max: 1000 } ,

fecha_de_creación: { tipo: Fecha, por defecto: nuevo Fecha() },

actualizado_a: { tipo: Fecha, por defecto: nuevo Fecha() }

}, { marcas de tiempo: { createdAt: "fecha_creada, updatedAt: "fecha_actualizada }})

Inmutable

Designar un campo como "Inmutable" conserva los valores originales e impide cualquier mutación en los campos designados. En la definición de timestamps del esquema, cada vez que se actualiza el documento tanto fecha_de_creación y actualizado_a se actualizan los campos.

Sin embargo, lo ideal sería que no quisiera que su fecha_de_creación a modificar. Esto se debe a que se utiliza para rastrear cuándo se creó un documento. Aquí es donde la opción inmutable resulta útil.

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default: 'airline' },
  name: { type: String, required: true  },
  country: { type: String, required: true, enum: ['United States', 'Canada'] },
  capacity: { type: Number, max: 1000 } ,
  created_at: { type: Date, default: new Date(), immutable: true},
  updated_at: { type: Date, default: new Date() }
}, { timestamps: { createdAt: 'created_at', updatedAt: 'updated_at' } })

const airlineSchema = nuevo Esquema({

id: { tipo: Cadena },

tipo: { tipo: Cadena, obligatorio: verdadero, por defecto: aerolínea },

nombre: { tipo: Cadena, obligatorio: verdadero },

país: { tipo: Cadena, obligatorio: verdadero, enum: [Estados Unidos, Canadá] },

capacidad: { tipo: Número, max: 1000 } ,

fecha_de_creación: { tipo: Fecha, por defecto: nuevo Fecha(), inmutable: verdadero},

actualizado_a: { tipo: Fecha, por defecto: nuevo Fecha() }

}, { marcas de tiempo: { createdAt: "fecha_creada, updatedAt: "fecha_actualizada } })

Hay ocasiones en las que se desea actualizar un campo inmutable. Esto es especialmente cierto en el caso de que se esté creando un documento y el campo inmutable no tenga un valor por defecto o cuando por alguna otra razón sea inevitable una actualización. En tal caso, puede pasar una opción adicional, nuevo : true...a la operación de mutación.

Este paso supone que el airlineSchema tiene un campo inmutable contacto, y está utilizando la operación modelo findOneandUpdate en aerolíneaModelo.

await airlineModel.findOneAndUpdate(
  { contact: { $like: '123456' } }, 
  { contact: '45678' }, 
  { new: true}
)

await aerolíneaModelo.findOneAndUpdate(

{ póngase en contacto con: { $como: '123456' } },

{ póngase en contacto con: '45678' },

{ nuevo: verdadero}

)

Ganchos

Ganchos en Ottoman son funciones asíncronas de middleware que escribes y registras con eventos predefinidos sobre los que podrías querer actuar antes de que se dispare el evento (pre-hooks) o después de que se dispare el evento (post-hooks).

Los ganchos deben definirse antes de definir los modelos, por lo que siempre es una buena práctica definir los ganchos junto con la definición del esquema en el flujo de trabajo.

Anteriormente señalamos que el actualizado_a se actualiza cuando se produce una mutación. Internamente, esto se logra con la ayuda de un pregancho que escucha un evento de actualización.

airlineSchema.pre('update', (doc) =&gt; {   
  doc[updatedAt] = typeof currentTime === 'function' 
    ? currentTime() 
    : currentTime
  return doc
})

airlineSchema.pre(actualizar, (doc) => {

doc[updatedAt] = tipode currentTime === función

? currentTime()

: currentTime

devolver doc

})

Normalmente, un gancho toma nombre del evento como primer argumento seguido de una función de devolución de llamada que será llamada eventualmente. Se pueden registrar ganchos para validar, guardar, actualizar y eliminar eventos.

Algunos de los casos de uso que podría considerar para registrar un gancho incluyen:

- Registro
- Limpieza de recursos
- Envío de notificaciones
- Actualización de otros documentos relacionados

Plugins

Una de las principales ventajas de utilizar Ottoman es el desarrollo ágil, porque no necesitas repetirte. En lugar de eso, acabas construyendo y utilizando componentes conectables que no solo ahorran tiempo y esfuerzo, sino que también producen código fácil de depurar y mantener.

Plugins extienden el comportamiento de los ganchos permitiéndole componentizar ciertas capacidades de manera que las construya una vez y las aplique a múltiples esquemas.

En este punto, suponga que todos sus esquemas tienen un campo llamado nombrey desea cambiar el valor a minúsculas cada vez que se guarda un documento. Esto puede lograrse absolutamente usando un pre-gancho en el evento de guardar, pero también tiene un requisito de que esto se aplique a todos los esquemas. En este caso se pueden utilizar plugins.

En este caso, estás definiendo un plugin "minúsculas" que convierte el valor asociado al nombre del campo a minúsculas:

const lowercase = (schema) =&gt; {
  schema.pre('save', (doc) =&gt; {   
    doc['name'] = doc['name'].toLowerCase()
    return doc
 })
}

const minúsculas = (esquema) => {

esquema.pre("guardar, (doc) => {

doc[nombre] = doc[nombre].toLowerCase()

devolver doc

})

}

A continuación, indique al esquema que utilice el complemento:

airlineSchema.plugin(lowercase)

1	airlineSchema.plugin(minúsculas)

También puedes registrar plugins globalmente para poder utilizarlos en todos los proyectos.

Tipos de esquema personalizados

Al sacarlo de la caja, Ottoman proporciona algunos tipos de esquema por defecto como cadena, número, booleano, fecha, matriz, etc. Sin embargo, hay ocasiones en las que es posible que desee construir un tipo de esquema personalizado complejo que sea reutilizable y esté bien definido.

Por ejemplo, supongamos que desea añadir URL_web a la airlineSchema. ¿Qué opciones tienes? La única opción disponible es la cuerda. No hay nada malo en elegir una cadena, sin embargo, la única advertencia es que no hay garantía de que el URL_web está bien formado. Este es un caso de uso típico en el que debería optar por un tipo de esquema personalizado.

La creación de un tipo de esquema personalizado es un proceso de tres pasos:

1. Defina el tipo de esquema personalizado:

class LinkType extends IOttomanType {
  constructor(name) {
    super(name, 'Link')
  }
  cast(value) {
    if(!isLink(String(value))) {
      throw new ValidationError(`Field ${this.name} only allows Link`)
    }
    return String(value)
  }
}

function isLink(value) {
  const regExp = new RegExp(
    /[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&amp;//=]*)?/gi
  )
  return regExp.test(value)
}

clase Tipo de enlace extiende IOttomanType {

constructor(nombre) {

super(nombre, Enlace)

}

fundición(valor) {

si(!isLink(Cadena(valor))) {

tirar nuevo ValidationError(`Campo ${este.nombre} sólo permite Enlace`)

}

devolver Cadena(valor)

}

función isLink(valor) {

const regExp = nuevo RegExp(

/[-a-zA-Z0-9@:%._\+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_\+.~#?&//=]*)?/gi

)

devolver regExp.prueba(valor)

}

La función isLink contiene la lógica para validar si una URL está bien formada.

2. Registre el tipo de esquema personalizado:

var LinkTypeFactory = (name) =&gt; new LinkType(name)
    registerType(LinkType.name, LinkTypeFactory)

1 2	var LinkTypeFactory = (nombre) => nuevo Tipo de enlace(nombre) registerType(Tipo de enlace.nombre, LinkTypeFactory)

3. Utilice el tipo de esquema personalizado:

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default: 'airline' },
  name: { type: String, required: true },
  country: { type: String, required: true, enum: ['United States', 'Canada']  },
  capacity: { type: Number, max: 1000 },
  created_at: { type: Date, default: new Date(), immutable: true},
  updated_at: { type: Date, default: new Date() },
  website_url: { type: LinkType } 
}, { timestamps : { createdAt: 'created_at', updatedAt: 'updated_at' } })

const airlineSchema = nuevo Esquema({

id: { tipo: Cadena },

tipo: { tipo: Cadena, obligatorio: verdadero, por defecto: aerolínea },

nombre: { tipo: Cadena, obligatorio: verdadero },

país: { tipo: Cadena, obligatorio: verdadero, enum: [Estados Unidos, Canadá] },

capacidad: { tipo: Número, max: 1000 },

fecha_de_creación: { tipo: Fecha, por defecto: nuevo Fecha(), inmutable: verdadero},

actualizado_a: { tipo: Fecha, por defecto: nuevo Fecha() },

URL_web: { tipo: Tipo de enlace }

}, { marcas de tiempo : { createdAt: "fecha_creada, updatedAt: "fecha_actualizada } })

Ahora, cada vez que se crea o actualiza un documento, URL_web se valida para una URL bien formada.

Validadores personalizados

Hay ocasiones en las que la comprobación de la integridad de un campo va más allá del uso de restricciones básicas como default, min, max, o tipos de esquema. Por ejemplo, es posible que desee declarar un tipo de campo como matriz, pero que también desee restringir la longitud de la matriz. En este caso, debe utilizar validadores personalizados.

Ampliemos el airlineSchema para aceptar una matriz de números de teléfono, pero no para aceptar más de dos números de teléfono. En primer lugar, es necesario registrar el validador utilizando el método addValidators como se muestra a continuación:

addValidators({
  phoneLength: (value) =&gt; {
    if(value.length &gt; 2) {
      throw new Error(`Only two phone numbers are allowed at the maximum.`)
    }
  }
})

const airlineSchema = new Schema({ 
  id: { type: String },
  type: { type: String, required: true, default:'airline' },
  name: { type: String, required: true  },
  country: { type: String, required: true, enum: ['United States', 'Canada']  },
  capacity: { type: Number, max: 1000 },
  created_at: { type: Date, default: new Date(), immutable: true },
  updated_at:{ type: Date, default: new Date() },
  website_url: { type: LinkType } ,
  phone_number: [{ type: String, validator: 'phoneLength' }]
}, { timestamps : { createdAt: 'created_at', updatedAt: 'updated_at' } })

addValidators({

phoneLength: (valor) => {

si(valor.longitud > 2) {

tirar nuevo Error(`Sólo dos teléfono números son permitido en el máximo.`)

}

})

const airlineSchema = nuevo Esquema({

id: { tipo: Cadena },

tipo: { tipo: Cadena, obligatorio: verdadero, por defecto:aerolínea },

nombre: { tipo: Cadena, obligatorio: verdadero },

país: { tipo: Cadena, obligatorio: verdadero, enum: [Estados Unidos, Canadá] },

capacidad: { tipo: Número, max: 1000 },

fecha_de_creación: { tipo: Fecha, por defecto: nuevo Fecha(), inmutable: verdadero },

actualizado_a:{ tipo: Fecha, por defecto: nuevo Fecha() },

URL_web: { tipo: Tipo de enlace } ,

número_teléfono: [{ tipo: Cadena, validador: Longitud del teléfono }]

}, { marcas de tiempo : { createdAt: "fecha_creada, updatedAt: "fecha_actualizada } })

Referencia

El modelado de datos -a veces denominado "diseño de documentos" en el mundo de las bases de datos NoSQL- es una parte esencial de la gestión de datos. En una base de datos relacional, los datos se almacenan en tablas y las relaciones entre tablas se gestionan mediante claves referenciales también conocidas como claves foráneas.

En Couchbase, los datos de tipos similares se almacenan dentro de las mismas colecciones, y hacen referencia a otros documentos utilizando una clave de documento (o simplemente "clave"). Cuando los documentos se diseñan de esta forma, Ottoman no sólo proporciona los medios para referirse a ellos durante el diseño del esquema, sino que también los rellena automáticamente utilizando el método populate.

Para entender mejor esta característica crearemos una ruta definiendo una ruta routeSchema y un routeModel. La ruta tiene un aerolínea que hace referencia a un modelo de línea aérea que utiliza el campo ref palabra clave.

const routeSchema = new Schema({
  id: { type: String } ,
  airline: { type: String, ref: 'Airline' },
  destination_airport: { type: String },
  source_airport: { type: String },
  stops: { type: Number },
  type: { type: String }
})
  
const routeModel = model('Route', routeSchema, { scopeName: "_default" })

const routeSchema = nuevo Esquema({

id: { tipo: Cadena } ,

aerolínea: { tipo: Cadena, ref: Aerolínea },

aeropuerto_de_destino: { tipo: Cadena },

aeropuerto_fuente: { tipo: Cadena },

para: { tipo: Número },

tipo: { tipo: Cadena }

})

const routeModel = modelo(Ruta, routeSchema, { scopeName: "_por defecto" })

A continuación creamos un documento de ruta que hace referencia al archivo aerolínea id 10.

const routeDocument = new routeModel({
  id: "route1",
  type: "route",
  source_airport: "LAX",
  destination_airport: "DFW",
  stops: 0,
  airline: "10"
})

const routeDocument = nuevo routeModel({

id: "ruta1",

tipo: "ruta",

aeropuerto_fuente: "LAX",

aeropuerto_de_destino: "DFW",

para: 0,

aerolínea: "10"

})

Llamando al guardar en el routeModel se crea un documento dentro del Ruta colección situada bajo el Por defecto ámbito de la base de datos Couchbase.

Por último, recuperamos el documento y lo rellenamos.

const laxRouteDocument = await routeModel.findOne( { source_airport: 'LAX' } )
await laxRouteDocument._populate('airline')

1 2	const laxRouteDocument = await routeModel.findOne( { aeropuerto_fuente: LAX } ) await laxRouteDocument.poblar(aerolínea)

Recuperamos el documento de ruta con los datos de la aerolínea incrustados, como se muestra a continuación:

{
  "id": "route1",
  "type": "route",
  "source_airport ": "LAX",
  "destination_airport": "DFW",
  "stops": "0",
  "airline": { 
    "id": "10",
    "type": "airline",
    "name": "MILE-AIR",
    "country": "United States"
  }
}

{

"id": "ruta1",

"tipo": "ruta",

"aeropuerto_de_origen ": "LAX",

"aeropuerto_destino": "DFW",

"paradas": "0",

"aerolínea": {

"id": "10",

"tipo": "aerolínea",

"nombre": "MILE-AIR",

"país": "Estados Unidos"

}

Generador de consultas

Ottoman tiene una API muy rica que maneja muchas operaciones complejas soportadas por Couchbase y el lenguaje de consulta SQL (anteriormente conocido como N1QL, como se utiliza a continuación).

El generador de consultas detrás de escena crea sus sentencias N1QL por usted. Al utilizar el Generador de consultas, tiene tres opciones de modo:

Índices

Índices juegan un papel importante en el acceso a sus documentos desde la base de datos Couchbase.

No disponer de los índices adecuados puede degradar el rendimiento. Por lo tanto, es esencial conocer de antemano el diseño de los documentos (es decir, el modelo de datos) y las consultas que se utilizarán con ellos. La creación de índices es un paso crucial cuando se trabaja con datos. Ottoman ofrece tres tipos de índices que puedes asociar a tu esquema.

Tipo de índice #1: NIQL

El índice N1QL es el tipo de índice por defecto utilizado por Ottoman, y en ocasiones también se denomina GSI o Global Secondary Indexes. Durante el proceso de arranque, Ottoman crea automáticamente varios índices secundarios, asegurando que algunas de las operaciones básicas sean eficientes desde el primer momento. Se trata de los más recomendado tipo de índice.

airlineSchema.index.findByName = {
  by: 'name',
  type: 'n1ql' 
}

airlineSchema.índice.findByName = {

por: nombre,

tipo: n1ql

}

Tipo de índice #2: Refdoc

El tipo de índice refdoc gestiona ciertos requisitos en los que es necesario garantizar la unicidad. Hay algunas cosas importantes que debes tener en cuenta antes de considerar un índice refdoc:

- Los índices refdoc son gestionados estrictamente por Ottoman y no por la base de datos Couchbase. Esto significa que cualquier actualización realizada en el documento fuera de Ottoman hará que el índice refdoc se desincronice.
- Los índices refdoc crean un documento binario adicional que contiene referencias a la clave del documento indexado. En pocas palabras, verá un documento adicional por cada documento que cree y que utilice el índice refdoc.

Por ejemplo, supongamos que desea asegurarse de que URL_web en airlineSchema es único. Se crearía un índice refdoc como se muestra a continuación:

airlineSchema.index.findByUrl = {
  by: website_url,
  type: 'refdoc'
}

airlineSchema.índice.findByUrl = {

por: URL_web,

tipo: refdoc

}

La mejor práctica general para el índice refdoc es tener precaución y manejar la mutación de datos estrictamente a través de Ottoman.

Tipo de índice #3: Vistas

Este tipo de índice está obsoleto y se eliminará en breve. Este tipo de índice sólo existe por compatibilidad con versiones anteriores. El uso de este índice es totalmente desaconsejado.

Lean

Ottoman proporciona muchos métodos modelo para recuperar documentos de una colección. Estos métodos incluyen encontrar, findById, findOneetc.

En encontrar es con diferencia el más popular y devuelve varios documentos en función de la condición de búsqueda especificada. La recuperación de un gran número de documentos a la vez a partir de una colección conlleva una sobrecarga de rendimiento que puede que no vea al trabajar con un conjunto más pequeño de documentos. La sobrecarga se debe principalmente a que todos los métodos modelo especificados devuelven una instancia de la clase Ottoman Document, que contiene mucha información de seguimiento de Ottoman-internal-state-of-change.

Activar la opción lean le dice a Ottoman que se salte la instanciación de un documento Ottoman completo y en su lugar sólo devuelva el objeto JavaScript plano (POJO).

Aunque esto puede aumentar su rendimiento, es una contrapartida a las características incorporadas de Ottoman como el seguimiento de cambios, validaciones, ganchos y métodos típicos de modelos como guardar, eliminar, etc. Por lo tanto, se recomienda utilizar lean con extrema precaución y atención.

const result =  await airlineMode.find( { name: { $like: 'american' } }, { lean: true }  )

1	const resultado = await airlineMode.encontrar( { nombre: { $como: "americano } }, { lean: verdadero } )

En resultado del ejemplo anterior tendrá todos los documentos de aerolíneas cuyo nombre sea como americanopero todos estos documentos serán JavaScript plano (es decir, se pierde toda la magia asociada a un documento otomano).

Métodos modelo

Barcos modelo Ottoman con varios métodos de ayuda que sirven para diferentes propósitos. A continuación se enumeran algunos de los métodos de modelos más utilizados:

encontrar: encontrar es un método genérico que utiliza el Servicio de Consulta entre bastidores y se utiliza para recuperar uno o más documentos de una colección de Couchbase basándose en la condición de filtro suministrada. Una forma eficiente de utilizar encontrar garantiza la creación de índices secundarios adecuados (es decir, índices N1QL).

La siguiente operación de búsqueda devuelve todos los documentos de líneas aéreas en los que el país es Estados Unidos e ignora la distinción entre mayúsculas y minúsculas.

const docs = await airlineModel.find({ country: "United States" }, { ignoreCase: true })

1	const docs = await aerolíneaModelo.encontrar({ país: "Estados Unidos" }, { ignoreCase: verdadero })

findOneAndUpdate: encontrar es un único documento basado en la condición de filtro que se le ha pasado y actualiza el documento con los nuevos valores proporcionados. Pasar una opción upsert : true garantiza la creación de un nuevo documento en caso de que no se encuentre ningún documento coincidente.

await airlineModel.findOneAndUpdate({ id: "10" }}, { country: "Canada" }, { upsert: true })

1	await aerolíneaModelo.findOneAndUpdate({ id: "10" }}, { país: "Canada" }, { upsert: verdadero })

Operaciones a granel: Hay casos en los que es posible que desee mutar más de un documento a la vez. Ottoman viene con tres métodos de modelo que ayudan con esta preocupación, y todos ellos utilizan el servicio de consulta detrás de las escenas:

- createMany: Crea varios documentos en una sola llamada
- removeMany: Elimina varios documentos en una sola llamada
- updateMany: Actualiza varios documentos en una sola llamada

El estado de respuesta para todas las operaciones masivas será "Éxito" siempre que no se produzca ningún error, en caso contrario será "Fallo".

Depuración

Como ya has visto, hay bastantes operaciones modelo que utilizan el lenguaje de consulta N1QL bajo el capó. Optimizar la consulta N1QL y crear los índices adecuados es una parte esencial del desarrollo.

Para ello, es importante saber qué tipo de consulta N1QL están utilizando estas operaciones modelo. Ottoman permite la depuración lo que da lugar a que se impriman sentencias N1QL en la consola de desarrollo que pueden ser utilizadas eficazmente por el desarrollador para analizar y crear índices mediante la interfaz de usuario apropiadamente.

¿En qué se diferencia Ottoman del SDK de Node.js?

Aunque Ottoman funciona con el SDK de Node.js, cabe destacar que hay ciertas funciones que sólo están disponibles a través de Ottoman. Es posible que desees considerar las siguientes características al elegir uno sobre el otro.

Característica	Otomano	SDK de Node.js
Esquema, restricciones	✅	🚫
Validadores	✅	🚫
Rellenar referencias	✅	🚫
Métodos de modelización (encontrar, encontrarUnoYactualizar, encontrarUnoYQuitar)	✅	🚫
Bootstrapping (crear ámbitos, colecciones, índices)	✅	🚫
Campos de auditoría (marca de tiempo)	✅	🚫
Índice Refdoc	✅	🚫
Ganchos	✅	🚫
Plugins	✅	🚫
Inmutable	✅	🚫
Generador de consultas	✅	🚫
Operaciones a granel	✅	🚫

Otros beneficios del uso del otomano

Espero que estés entusiasmado y preparado para escribir tu primera aplicación utilizando Ottoman. Las siguientes son algunas de las principales razones por las que nuestros clientes prefieren Ottoman:

Adaptabilidad
No necesitas conocimientos especializados, todo lo que necesitas es saber JavaScript o TypeScript y listo.

Asequibilidad
Disfrute de todas las ventajas del código abierto. No hay dependencia de un proveedor, se reducen los gastos de capital, no hay licencias propietarias, etc.

Apoyo y sostenibilidad
Deje en nuestras manos la carga de escanear y parchear el software en busca de vulnerabilidades de seguridad. Obtenga actualizaciones de software constantes para alinearse con las versiones del servidor y reciba asistencia completa de nuestro equipo de soporte y de la amplia comunidad de desarrolladores.

Agilidad
Sea líder en su sector: cree y entregue aplicaciones de forma rápida y puntual. No hay necesidad de construir su capa de datos desde cero. Dedique su tiempo a resolver problemas empresariales en lugar de a codificar. Escribe bloques de código más pequeños que sean fáciles de mantener y leer. Tu código se parecerá incluso después de muchas iteraciones porque es así de sencillo.

Calidad de los datos
Garantizar la calidad de los datos utilizando esquemas, validadores, restricciones y otros módulos disponibles. Producir código libre de errores con la fontanería de Ottoman, que es el resultado de una observación bien pensada y elaborada de los retos repetitivos de diseño y desarrollo. Ottoman resuelve muchos problemas comunes que de otro modo pueden ser difíciles y propensos a errores si se codifican a mano.

Empiece hoy mismo con Ottoman

Ahora que tienes una comprensión básica de por qué y cuándo deberías considerar Ottoman para tu próximo proyecto Node.js, ¡es hora de ensuciarse las manos!

Aquí tienes algunos enlaces útiles para empezar:

¿Listo para probar Ottoman?
Empiece con un proyecto de muestra aquí

Arun Vijayraghavan

Platform

Self-Managed

Services

Capabilities

Why Couchbase?

Migrate to Capella

By Use Case

By Industry

By Application Need

Popular Docs

By Developer Role

Quickstart

Resource Center

About

Partnerships

Our Services

Partners: Register a Deal

Ready to register a deal with Couchbase?

Marriott

Todos los mensajes

Presentamos Ottoman v2.0: Un ODM para Node.js y Couchbase

Por qué necesita un ODM para Couchbase

Ottoman facilita el desarrollo en Node.js

Esquemas y modelos de datos

Marcas de tiempo

Inmutable

Ganchos

Plugins

Tipos de esquema personalizados

Validadores personalizados

Referencia

Generador de consultas

Índices

Lean

Métodos modelo

Depuración

¿En qué se diferencia Ottoman del SDK de Node.js?

Otros beneficios del uso del otomano

Empiece hoy mismo con Ottoman

Autor

Publicado por Arun Vijayraghavan

Dejar una respuesta Cancelar respuesta