For some reason I cannot get the has_many/belongs_to relationship to work. The nested content type does not show up in the parent. Here is what I have:
app/content_types/news_photos.yml
- article:
label: News articles
type: belongs_to
target: news_articles
app/content_types/news_articles.yml
- news_photos:
label: News photos
type: has_many
target: news_photos
class_name: news_photos
inverse_of: news_article
required: false
hint: A description of the field for the editors
localized: false
ui_enabled: true
Thanks for the help!
I'm not sure if you got to the solution but the issue is in fact in naming.
The has_many definition should have inverse_of: article
The value of inverse_of should be the name of the attribute that has the belongs_to relation in other model, in this case news_photos.
Related
OctoberCMS Build: 469
PHP Version: 7.3
Database Engine: MySQL
Plugins Installed: Rainlab.Builder, Rainlab.Translate, Inetis.RichEditorSnippets, Rainlab.Pages
Description:
I have followed the tutorial to make List and Form with nested Relations (https://octobercms.com/support/article/ob-21).
I open a model, and inside this model, i have a relation that have many relations like below :
-- Residence
--- Pages
---- Sections
In the "Section" popup, i display a richeditor, with snippets. But when i click on the snippet to open and edit properties, it can't focus the input.
I have search a long time in the source code of all OctoberCms, but i did not find anything.
After many tries, i have found that if in the browser inspector, i delete formPopups, the focus enables.
Here is an example of what i have actually.
Here is an example where i delete the second popup in the browser inspector
Does someone already had this issue ? Is there any fix for ?
EDIT :
Steps to reproduce
To help you to reproduce this,
you need to make 3 models with those fields :
1. Residence - fields.yaml
fields:
name:
label: Residence
span: left
required: 1
type: text
pages:
type: partial
path: pages
home_content:
label: 'Residence Content'
size: large
span: full
type: richeditor
2. Page - fields.yaml
fields:
title:
label: Titre
span: left
required: 1
type: text
sections:
span: full
path: pages_sections
type: partial
3. Section - fields.yaml
fields:
title:
label: Title
span: left
required: 1
type: text
content:
label: Content
size: ''
span: full
required: 1
type: richeditor
And you need to create relations in your models :
Residence.php
public $hasMany = [
'pages' => [
'Author\Plugin\Models\Page'
]
];
Page.php
public $hasMany = [
'sections' => [
'Author\Plugin\Models\Section'
]
];
Then you need to follow the tutorial on Making form with nested relations (https://octobercms.com/support/article/ob-21) to be able to open the relation between Page and Section inside the Residence Form.
Do not hesitate to ask me for more informations,
Best,
I know there are a lot of similar questions, but they're too old and since Mongodb has evolved alot for last 5-6 years I am looking for a good schema design.
Goal: I want to have a post with comments by users.
What I have designed so far is:
Separate post model:
const projectSchema = new mongoose.Schema({
user: { type: mongoose.Schema.Types.ObjectId, required: true, ref: 'User' },
title: { type: String, required: true },
image: { type: String, default: undefined },
description: { type: String, required: true, minLength: 200, maxlength: 500 },
comments: [{
type: mongoose.Schema.Types.ObjectId, ref: 'Comment'
}],
state: { type: Boolean, default: true },
collaborators: { type: Array, default: [] },
likes: { type: Array, default: [] }
})
And a separate comments model:
const commentSchema = new mongoose.Schema({
comment: { type: String, required: true },
project: { type: String, required: true, ref: 'Project' },
user: { type: String, required: true, ref: 'User' }
})
The reason I am going for the relational approach is because if the comments increase to say 10,000 in number, it will increase the size of schema by alot.
This way, no matter how many comments we can populate them using their IDs, also, we will have different collection for comments iself.
Reference : one-to-many
Is this a good approach for my project?
The way I am querying the comments from one single post:
const project = await Project.findById(
new mongoose.Types.ObjectId(req.params.projectId)
).populate({
path: 'comments',
populate: { path: 'user' }
}).lean()
Whether it's a good design depends how many comments per post do you expect, and what query will be performed on your app.
There's a good blog from mongodb.com on how to design your database schema
The common design is:
One to Few (Use embed)
One to Many (Use embed reference)
One to squillions (The usual relational database one-to-many approach)
Summary is:
So, even at this basic level, there is more to think about when designing a MongoDB schema than when designing a comparable relational schema. You need to consider two factors:
Will the entities on the “N” side of the One-to-N ever need to stand alone?
What is the cardinality of the relationship: is it one-to-few; one-to-many; or one-to-squillions?
Based on these factors, you can pick one of the three basic One-to-N schema designs:
Embed the N side if the cardinality is one-to-few and there is no need to access the embedded object outside the context of the parent object
Use an array of references to the N-side objects if the cardinality is one-to-many or if the N-side objects should stand alone for any reasons
Use a reference to the One-side in the N-side objects if the cardinality is one-to-squillions
There is also a blog about advanced schema design which is worth the read.
You seems to be using the two-way referencing approach.
The difference between yours and one-to-squillions is you are not only storing post id reference on comment document, but also storing comment ids as reference in post document, while one-to-squillions will only stores project id reference in comment document.
Using your approach will be better if you need to get comment ids of a post. But the disadvantage is you need to run two queries when deleting or creating a comment, one to delete / create comment id from post, and the other one to delete / create the comment document it self. It's also will be slower to find "which post belongs to given comment id".
While using one-to-squillions would gives you worse performance when performing a query to get comments by post id. But you can mitigate this by properly indexing your comment collection.
take a look in this code:
#prop({
required: true,
autopopulate: true,
ref: Fund || Project,
})
organization: Ref<Fund> | Ref<Project>;
the property "organization" type can be Fund or Project.
in this example when the type is "Fund" i get the object. but when the type is "Project" i get null.
I dont know nest so much and I am starter in nest. I started using it very recently.
how can i solve that problem??
thanks.
You need two field to achieve this, first is the reference on what model the field refers to and the second is the objectid you stored to.
Note: on the name at enum,
Class Person {
#prop({required: true, enum: 'Fund' | 'Project'})
which: string;
#prop({refPath: "which"})
organization: Ref<Fund | Project>;
}
For reference just check this mongoose official docs
I've been enjoying the new Sails relationships in v0.10, but my biggest challenge currently is looking up models by their associations. If I were to have populated a manual association, say, an array of IDs, this would be pretty easy. However, I can't seem to find the right way of handling the lookups with a Sails association.
I've provided some sample code that outlines two models, a Company and a User. Companies can have many Users, and a User can have only one Company. This is a pretty straight forward one-to-many relationship, and the goal is to find all Companies that match a User ID.
## Company.js
name:
type: 'string'
required: true
users:
collection: 'User'
via: 'company'
## User.js
company:
model: 'Company'
required: true
last_name:
type: 'string'
required: true
first_name:
type: 'string'
required: true
## Lookup Users by Company ID of '2'
User.find(where: company: 2).exec(console.log)
# Result
# [] - Array of users matching that company ID
## ---- The Problem / Question ----
## Lookup Companies by User ID '1'
Company.find(where: users: contains: 1).exec(console.log)
# Result
# Error (E_UNKNOWN) :: Encountered an unexpected error:
# error: column company.users does not exist
# Details:
# { error: 'E_UNKNOWN',
# summary: 'Encountered an unexpected error',
# status: 500,
# raw: 'error: column company.users does not exist' }
I'd appreciate any thoughts on the best way to handle this lookup!
In the case of querying "all companies whose list of users contains #1", you're trying to do a subquery, which Waterline does not currently support. Furthermore, it's a slightly silly example since every user can only have one company, so you should only ever expect one result. In any case the correct method would simply be to look up User #1 and populate its company:
User.findOne(1).populate('company').exec(function(err, user) {
console.log(user.company);
});
I'll leave it to you to translate that to Coffeescript ;)
To find all of a company's users, you'd do something similar:
Company.findOne(123).populate('users').exec(...)
You can filter the populated results, but it's not the same as a subquery:
Company.findOne(123).populate('users', {where: {id: [1,2,3]}}).exec(...)
This would get you company #123 and populate its users array only with users with ID values of 1, 2 or 3.
Is it possible to limit available displayed options in a relationship type of KeystoneJS by specifying a value condition?
Basically, a model has two sets of array fields, instead of letting the admin user select any item from the field, I would like to restrict to only the items that are part of a specific collection _id.
Not sure if this is exactly the feature you're looking for, but you can specify a filter option on the Relationship field as an object and it will filter results so only those that match are displayed.
Each property in the filter object should either be a value to match in the related schema, or it can be a dynamic value matching the value of another path in the schema (you prefix the path with a :).
For example:
User Schema
User.add({
state: { type: Types.Select, options: 'enabled, disabled' }
});
Post Schema
// Only allow enabled users to be selected as the author
Post.add({
author: { type: Types.Relationship, ref: 'User', filter: { state: 'enabled' } }
});
Or for a dynamic example, imagine you have a role setting for both Posts and Users. You only want to match authors who have the same role as the post.
User Schema
User.add({
userRole: { type: Types.Select, options: 'frontEnd, backEnd' }
});
Post Schema
Post.add({
postRole: { type: Types.Select, options: 'frontEnd, backEnd' },
// only allow users with the same role value as the post to be selected
author: { type: Types.Relationship, ref: 'User', filter: { userRole: ':postRole' } }
});
Note that this isn't actually implemented as back-end validation, it is just implemented in the Admin UI. So it's more of a usability enhancement than a restriction.
To expand on Jed's answer, I think the correct property (at least in the latest version of KeystoneJS 0.2.22) is 'filters' instead of 'filter'. 'filter' doesn't work for me.