I'm trying to store a large chunk of text as part of a model in Sails.js. However, it seems that the text is getting cut off after some length. Is there a limit set on how long the 'string' type can hold in a model? If so, what's the best way around it? For reference, I'm using sails-mysql as an adapter.
Yes, String is only 255 chars long on default (because thats the default length in the most databases).
Try to use
myfield: {
type: "text"
}
As attribute - this should work.
(See: http://beta.sailsjs.org/#/documentation/reference/Models/Attributes.html)
Try to use
field: {
type: 'ref'
}
this creates longtext in mysql .
Related
I am using TypeORM to run this query:
SELECT "subagreementlog"."created_at" AS "subagreementlog_created_at" FROM "subagreement_logs" "subagreementlog" WHERE "subagreementlog"."subagreement_id" = $1 AND "subagreementlog"."created_at" > $2 LIMIT 1 -- PARAMETERS: ["0d71866e-3b78-4321-8ae8-dc39ffe82dbc","2020-11-12T13:57:16.618Z"]
I am looking for a record where the "created_at" value is greater than "2020-11-12T13:57:16.618Z" but this is actually returning the same value as if I was saying equal to or greater than.
result is: { subagreementlog_created_at: 2020-11-12T13:57:16.618Z }
Looking for guidance as to why this may be the case.
Also, here is the definition for said field in the Entity
#CreateDateColumn({ name: "created_at" })
#Field(_ => GraphQLISODateTime, {
description: "Timestamp the subagreement was changed"
})
public createdAt!: Date;
Have you tried increasing your parameter value? For example, rather than
2020-11-12T13:57:16.618Z try 2020-11-12T13:57:17.618Z (+1 second)
I believe you will still get a match even though the data is clearly before the parameter.
If you get a match I suspect what is happening is that you are storing data in one timezone (UTC likely) but using a local time for your parameter. I do not know TypeORM but maybe it converts timezones on reads and writes but does not convert parameters.
Just a guess but I hope it helps.
I've just spent a good hour figuring out something mind-boggling (at least to me, as a JS noob) and I'd like to understand the underlying logic (or just why it works this way, because I think it's illogical and quite unexpected).
Suppose I'm using Mongoose to retrieve documents from a database, some or all of which include a date property (created with new Date()), a numeric property, and a string property.
[{
string: 'foo',
date: '2018-10-13T21:11:39.244Z',
number: 10
},
...
{
string: 'bar',
date: '2018-10-13T21:12:39.244Z',
number: 20
}]
I thus obtain an array of objects and now want to take the date property for each object and change the value to a string, so I do something like:
doc.find({}, (err, list) => {
list.forEach((item, index) => {
list[index].date = 'new value'
})
})
But I can't do that!
I can do list[index].string = 'new value' as well as list[index].date = new Date() but I can't change values that are of a different type, in this example date and number.
However, when I do list[index]._doc.date = 'new value', which took so long to figure out because I didn't know Mongoose objects weren't just plain old objects and focused on solving problems I didn't have instead, I can modify the value just fine.
It appears that the mongoose object somehow translates obj.key to obj._doc.key only if the type of the value matches but I'd appreciate a more detailed explanation than my uneducated guesses.
I suppose you want to use multi type on a document field, Mongoose support this by "Mixed" type when you define the Schema.
You can get more detail from https://mongoosejs.com/docs/schematypes.html#mixed.
I am writing a mongoose schema, and I would like to understand the properties of the same.
Here is my schema:
var UserSchema = new Schema({
name: String,
username: { type: String, required: true, index: { unique: true }},
password: { type: String, required: true, select: false }
});
Why required is not declared for `name' - ?
Why required declared?
What is select - true/false -means?
When the index - should declared any why?
Why required is not declared for `name' - ?
Answer: When a field is mandatory to fill then in that case we mention it as required. So here "name" is not required or mandatory field.
Why `required' declared?
Answer: As mentioned above, When a field is mandatory to be filled then in that case we mention it as required.
What is select - true/false -means?
Answer: This means that it will not be returned by default in the data when you fetch the document. you can specify if this path should be included or excluded from query results by default.
Schema options
When the index - should declared any why?
Answer: Index should be declared when you are searching data on that field frequently so when you create indexing on that field in that case it do not search that field in all the collections it will search value for that field using index and will return result very quickly.
How indexes work in mongodb
Here, these act as model for your project. So, required is used as validation and index is working as index over that field
Now you have two ways :
either put validation over here in schemas/models
or just manually create validation for form at frontend using JS/Jquery and then long route
Now your answers:
Name is not compulsory to be filled in. That's why no required is put over there.
when there is mandatory to fill any value for that field. Then required is used in schemas.
True/False enables or disables the usage of validation over that field. If you are using false means filling in for that field isn't compulsion at all. But using false is considered a good practice.
Index is special data structure which are used for increasing performance during read/search operations. It increases the speed of operations and are stored in memory.
whenever we have to validate the particular field, so we used required.
required: true means you must fill that field.
required: false means you may or may not fill that field, but its a good practice.
In my User Schema I have various fields with various default values. By example, see a few fields below:
acceptedStatus: {
type: String,
trim: true,
default: 'no' //possibilities (no, yes, thinkingAboutIt, yesInFuture)
}
Is there a way to quickly return the saved data for a particular field to its default value without explicitly doing it like
user.acceptedStatus = 'no';
and, if so, is there a way to return all fields that carry default values to their original status. Thanks for your help. There are times when I need to quickly do this, and didn't know if there were any methods I am missing.
One way could be that you store schema in an object, then from that object you can easily come to know what property have defaults.
I was trying to make my model strings to be always uppercase, so I tried to use converter and reverseConverter to do this job. Using the mutual option I got hitted by this topic.
Witch leads to my question. Is this the right use case to converter? Without the mutual the value was converted only in the model, and didn't update the view.
Can I use the DocumentFilter approach?
Example
textField(columns: 3, text: bind("score", target: m,
converter: { it.isEmpty()? 0: Integer.parseInt(it) },
reverseConverter: { String.valueOf(it) },
mutual: true))
I'm afraid converter: and reverseConverter: only work with unidirectional bindings at the moment.