Sails.js and pluralized relational database table names - sails.js

How do I configure Sails.js / Waterline to default to pluralized relational database table names that correspond to singular models (same as Rails)?
(E.g. A model called 'Person' should default to a PostgreSQL table called 'people'.)

Just add the tableName: 'people' property to the model:
// Person.js
module.exports = {
tableName: 'people',
attributes: {
id: 'integer',
name: 'string'
}
};
There does not appear to be a global setting in Sails.js that pluralizes database table names automatically for models with singular names.

You can put this in your blueprints.js or local.js file:
blueprints: { // if in your local.js wrap in this object
pluralize: true
}
It won't get it right every time, so the tableName property is still useful for odd cases, but for most pluralized terms it will work.

Related

Is it possible to work with different schemas in Fluent with PostgreSQL?

I need to create tables with different number of fields for different users. I want to create a schema for each user, and in it a custom set of tables. I can do this with direct database queries. This will create a categories table in the schema with the given name.:
func create(in schema: String, on db: Database) async throws {
let query: SQLQueryString = """
CREATE TABLE IF NOT EXISTS \(raw: schema).categories (
id uuid PRIMARY KEY,
name text NOT NULL,
...
);
"""
if let sql = db as? SQLDatabase {
try await sql.raw(query).run()
}
}
But I would like to do this with Fluent. (the my_schema schema and the necessary rights to it were previously created in the database) But the following code creates the "my_schema.categories" table in the public schema:
func create(in schema: String, on db: Database) async throws {
try await db.schema("\(schema).categories")
.id()
.field("name", .string, .required)
...
.create()
}
Is it possible to work with different schemas in Fluent and how to query tables from different schemas? I will be grateful for any ideas.
Yes, this was recently introduced to Fluent. Update to the latest version and then you can add a new static property on your model:
final class MyModel: Model {
static let schema = "table_name"
static let space = "schema_name"
// ...
}
See the docs for more details.
Hopefully I am understanding your exact request correctly. If so, using multiple schemas is pretty simple.
(1) First in your configuration define your schema connections, making sure to specify DatabaseID and defaults:
app.databases.use(.postgres(connection_info), as: .psql, isDefault: true)
app.databases.use(.postgres(connection_info), as: .otherDB, isDefault: false)
(2) Run your create table migrations specifying the database schema to add the table to:
app.migrations.add(MigrateCategories())
app.migrations.add(MigrateSomeOtherTable(), to: .otherDB)
(3) Query tables from different database schemas:
categories.create(on: req.db())
someOtherTable.create(on: req.db(.otherDB))
Now you've got two databases
.psql is default and has one table called categories
.otherDB has one table called someOtherTable
Use the DatabaseID to indicate where you want to create new tables and where you want to run queries.

Advantages of using Virtuals in Mongoose

i would like to kmow the advantages of using virtuals in mongoose while establishing relationship. Will it result in faster retrival of information from DB
Virtuals are additional fields for a given model. Their values can be set manually or automatically with defined functionality. A common virtual property is the full name of a person, composed of user’s first and last name.
virtual properties don’t get persisted in the database. They only exist logically and are not written to the document’s collection.
Example
Mongoose Schema
The user schema has two properties indicating the user’s first and last name: first and last.
// define user schema
var userSchema = new Schema({
first: String,
last: String
});
// compile our model
var User = mongoose.model('User', userSchema);
// create a document
var mentalist = new User({
first: 'Patrick',
last: 'Jane'
});
Assume we want to get the full name of a mentalist, we can do this manually appending the first to last property:
console.log(mentalist.first + ' ' + mentalist.last); // Patrick Jane
Define a Virtual Property
Actually, there is a better way of getting the full name of a user: virtual fields. With virtuals, you benefit of writing the name concatenation mess only once.
Mongoose splits the definiton of virtual fields into GET and SET methods.
Get Method
The virtuals get method is a function returning a the virtual value. You can do complex processing or just concatenate single document field values.
userSchema.virtual('fullname').get(function() {
return this.first + ' ' + this.last;
});
The code example above just concatenates the first and last property values. With that, the virtual fullname property now will print the same output as above:
console.log(mentalist.fullname); // Patrick Jane
Set Method
setter methods are useful to split strings or do other operations. Define a virtual setter by passing a proper function and execute your desired processing. The example below splits the passed name variable at any whitespace.
userSchema.virtual('fullname').set(function (name) {
var split = name.split(' ');
this.first = split[0];
this.last = split[1];
});
The first part of name is assigned to the first and the second part to the last property. This set method will override the previous model values and assign the ones we pass as fullname property.
var humor = new User({
first: '',
last: ''
});
humor.fullname = 'Kimball Cho';
console.log(humor.first); // Kimball
console.log(humor.last); // Cho
Queries and Field Selection
Virtuals are NOT available for document queries or field selection. Only non-virtual properties work for queries and field selections.
As you see, virtual properties aren’t static model properties. They
are additional model functions returning values based on the default
schema fields.

Populate a query in Mongoose with Schema First approach and NestJS

First off I want to say this question is similar to this one which references this one. I have the exact same question as the second link except a notable difference. I'm trying to extend a class generated by NestJS which defines a property.
I'm using NestJs with the Schema first approach found here. I'm also generating a classes file based on my GraphQL Schema.
Here is the Schema:
type Location {
name: String!
owner: User!
}
Which generates the class:
export class Location {
name: string;
owner: User;
}
Now, I want to extend this class so I don't have to repeat the data (there are a lot more fields not shown). I also I want to add fields that live on a document but are not in the schema (_id in this example). Here is my LocationDocument and my schema.
export interface LocationDocument extends Location, Document {
_id: Types.ObjectId
}
export const LocationSchema: Schema = new Schema(
{
name: {
type: String,
required: true,
},
owner: {
type: Types.ObjectId,
ref: 'User',
}
);
Now here is my issue. The generated Location class from the GraphQL schema defines the owner property as a User type. But in reality it's a just a mongodb id until it is populated by Mongoose. So it could be a Types.ObjectId or a User on a UserDocument. So I attempted to define it as:
export interface LocationDocument extends Location, Document {
_id: Types.ObjectId
owner: User | Types.ObjectId;
}
But this throws an error in the compiler that LocationDocument incorrectly extends Location. This makes sense. Is there any way to extend the User Class but say that owner property can be a User Type (once populated by Mongoose) or a mongo object ID (as is stored in the database).
I decided that having a property that can be both types, while easy with Mongoose and JS, isn't the typed way. In my schema I have an owner which is a User type. In my database and the document which extends it, I have an OwnerId. So to people accessing the API, they don't care about the ownerId for the relationship. But in my resolver, I use the Id. One is a Mongo ID type, the other is a User type.

Associations with combination foreign key in Sails.js/Waterline

I need to have a model called 'Package' which can have one or more children of several different types. For example, a package can contain guides, as well as forms and other content types (some of which will be added later). Each of these content items, from different tables, can be in multiple packages. So I have the following schema:
Package table
=============
id
name
....
PackageContent table
=============
id
packageId
contentType
contentId
Guide table
=============
id
name
...
Form table
=============
id
name
How can I define the 'content' association for my packages in my Package.js model file in sails.js? I have not been able to find any information on combination foreign keys in sails.js or Waterline. I would hope to find something along the lines of:
// models/Package.js
module.exports = {
attributes = {
name: 'text',
....
content: {
through: 'PackageContent',
collection: contentType,
via: 'contentId'
}
}
};
I have a similar problem recently. My solution is to create different foreign keys in the intermediary model and set attributes as 'required:false'. In your example, the PackageContent table could look like this:
//PackageContent.js
module.exports={
attributes={
package:{
model:'package',
},
guide:{
model:'guide'
require:false
},
form:{
model:'form'
require:false
}
//other attributes...
}
}
In order to avoid duplicated package+content combination, you may need to write a beforeValidate method to check the duplication. I am not sure if this is a 'good design', but it solves the probelm

How to avoid DROP DEFAULT statements with Doctrine 2 Migrations diff on first run?

I had an existing PostgreSQL database with a table created like this:
CREATE TABLE product (id SERIAL PRIMARY KEY, name VARCHAR(100) DEFAULT NULL)
This table is described in a YML Doctrine2 file within a Symfony2 project:
Acme\DemoBundle\Entity\Product:
type: entity
table: product
fields:
id:
id: true
type: integer
nullable: false
generator:
strategy: SEQUENCE
name:
type: string
length: 100
nullable: true
When I run for the first time the Doctrine Migrations diff task, I should get a versioning file with no data in the up and down methods. But what I get instead is this :
// ...
class Version20120807125808 extends AbstractMigration
{
public function up(Schema $schema)
{
// this up() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != "postgresql");
$this->addSql("ALTER TABLE product ALTER id DROP DEFAULT");
}
public function down(Schema $schema)
{
// this down() migration is autogenerated, please modify it to your needs
$this->abortIf($this->connection->getDatabasePlatform()->getName() != "postgresql");
$this->addSql("CREATE SEQUENCE product_id_seq");
$this->addSql("SELECT setval('product_id_seq', (SELECT MAX(id) FROM product))");
$this->addSql("ALTER TABLE product ALTER id SET DEFAULT nextval('product_id_seq')");
}
}
Why are differences detected? How can I avoid this? I tried several sequence strategies with no success.
A little update on this question.
Using Doctrine 2.4, the solution is to use the IDENTITY generator strategy :
Acme\DemoBundle\Entity\Product:
type: entity
table: product
id:
type: integer
generator:
strategy: IDENTITY
fields:
name:
type: string
length: 100
nullable: true
To avoid DROP DEFAULT on fields that have a default value in the database, the default option on the field is the way to go. Of course this can be done with lifecycle callbacks, but it's necessary to keep the default value in the database if this database is used by other apps.
For a "DEFAULT NOW()" like default value, the solution is the following one:
Acme\DemoBundle\Entity\Product:
type: entity
table: product
id:
type: integer
generator:
strategy: IDENTITY
fields:
creation_date:
type: datetime
nullable: false
options:
default: CURRENT_TIMESTAMP
Doctrine 2.0 does not support the SQL DEFAULT keyword, and will always try to drop a postgres default value.
I have found no solution to this problem, I just let doctrine handle the sequences itself.
This is a opened bug registered here :
http://www.doctrine-project.org/jira/browse/DBAL-903