Warning
The Model is valid.
Changes made to the model include changes to fields types.
Those changes may result in a loss or corruption of data.
Click Ok to proceed
field: vIdAux, kind: field type conflict, newType: float, oldType: string, relation: AUXAUDIobjectS
field: vIdAuxdet, kind: field type conflict, newType: float, oldType: string, relation: AUXDETALLES
field: vIdAux, kind: field type conflict, newType: float, oldType: string, relation: AUXDETALLES
Changing fields type in Backand can be done from the JSON only.
Some changes can't be done, like from Text to float and others and you should get an error message about it, others will be OK to change. You can always access the Database directly and make the changes there.
Related
Working on a module for Odoo 14 CE
My module depends from another module called "base_locations"
base_locations extends the functionalities related to inserting data about cities and regions in the standard Odoo but it's distributed by the Odoo Community Association, so I assume it's pretty standard stuff
In one of my views I have a "city" field
<field name="city"/>
The field "city" is defined in a model belonging to the base_location module
But when I try to access the view, this error pops up in the web GUI
Error: While parsing modifiers for field city: for modifier "readonly": Unknown field type in domain
_registerModifiers#http://localhost:8069/web/static/src/js/views/basic/basic_renderer.js:633:23
_renderFieldWidget#http://localhost:8069/web/static/src/js/views/basic/basic_renderer.js:727:30
_renderFieldWidget#http://localhost:8069/web/static/src/js/views/form/form_renderer.js:530:21
OdooClass.extend/</prototype[name]</<#http://localhost:8069/web/static/src/js/core/class.js:90:38
_renderInnerGroupField#http://localhost:8069/web/static/src/js/views/form/form_renderer.js:677:24
_renderInnerGroup/<#http://localhost:8069/web/static/src/js/views/form/form_renderer.js:641:29
_renderInnerGroup#http://localhost:8069/web/static/src/js/views/form/form_renderer.js:613:23
_renderTagGroup#http://localhost:8069/web/static/src/js/views/form/form_renderer.js:866:25
_renderNode#http://localhost:8069/web/static/src/js/views/form/form_renderer.js:722:29
_renderNode#http://localhost:8069/mail/static/src/widgets/form_renderer/form_renderer.js:140:21
OdooClass.extend/Class.include/</prototype[name]</<#http://localhost:8069/web/static/src/js/core/class.js:123:38
_renderTagForm#http://localhost:8069/web/static/src/js/views/form/form_renderer.js:852:38
_renderNode#http://localhost:8069/web/static/src/js/views/form/form_renderer.js:722:29
_renderNode#http://localhost:8069/mail/static/src/widgets/form_renderer/form_renderer.js:140:21
OdooClass.extend/Class.include/</prototype[name]</<#http://localhost:8069/web/static/src/js/core/class.js:123:38
_renderView#http://localhost:8069/web/static/src/js/views/form/form_renderer.js:1054:26
_render#http://localhost:8069/web/static/src/js/views/abstract_renderer.js:141:20
_render#http://localhost:8069/web/static/src/js/views/basic/basic_renderer.js:675:20
OdooClass.extend/</prototype[name]</<#http://localhost:8069/web/static/src/js/core/class.js:90:38
start#http://localhost:8069/web/static/src/js/views/abstract_renderer.js:55:33
OdooClass.extend/</prototype[name]</<#http://localhost:8069/web/static/src/js/core/class.js:90:38
start#http://localhost:8069/web/static/src/js/views/form/form_renderer.js:53:28
OdooClass.extend/</prototype[name]</<#http://localhost:8069/web/static/src/js/core/class.js:90:38
_widgetRenderAndInsert/<#http://localhost:8069/web/static/src/js/core/widget.js:440:25
If I comment out this city field, the view works
How do I go about this error message ?
Especially the first line is quite obscure to me
Error: While parsing modifiers for field city: for modifier "readonly": Unknown field type in domain
which parsing phase is this referring to, exactly ?
And field type ? Domain ?
I don't get what this mesage is refering to
I have a table where it's beneficial to generate a pre-calculated value in the database engine rather than in my application code. For this, I'm using Postgres' generated column feature. The SQL is like this:
ALTER TABLE "Items"
ADD "generatedValue" DOUBLE PRECISION GENERATED ALWAYS AS (
LEAST("someCol", "someOtherCol")
) STORED;
This works well, but I'm using Sequelize with this database. I want to find a way to define this column in my model definition, so that Sequelize will query it, not attempt to update a row's value for that column, and ideally will create the column on sync.
class Item extends Sequelize.Model {
static init(sequelize) {
return super.init({
someCol: Sequelize.DOUBLE,
someOtherColl: Sequelize.DOUBLE,
generatedValue: // <<<-- What goes here??
});
}
}
How can I do this with Sequelize?
I can specify the column as a DOUBLE, and Sequelize will read it, but the column won't be created correctly on sync. Perhaps there's some post-sync hook I can use? I was considering afterSync to drop the column and re-add it with my generated value statement, but I would first need to detect that the column wasn't already converted or I would lose my data. (I run sync [without force: true] on every app startup.)
Any thoughts, or alternative ideas would be appreciated.
Until Sequelize supports readOnly fields and the GENERATED datatype, you can get around Sequelize with a custom datatype:
const Item = sequelize.define('Item', {
someCol: { type: DataTypes.DOUBLE },
someOtherCol: { type: DataTypes.DOUBLE },
generatedValue: {
type: 'DOUBLE PRECISION GENERATED ALWAYS AS (LEAST("someCol", "someOtherCol")) STORED',
set() {
throw new Error('generatedValue is read-only')
},
},
})
This will generate the column correctly in postgres when using sync(), and prevent setting the generatedValue in javascript by throwing an Error.
Assuming that sequelize never tries to update the field if it hasn't changed, as specified in https://sequelize.org/master/manual/model-instances.html#change-awareness-of-save, then it should work.
The data source in PowerApps gallery was a SQL View.
Search('[dbo].[vwCandidate]', textSearchCandidate.Text, "NameLast", "NameFirst", "MiscellaneousTags", "EmailAddress", "PhoneNumber")
The selected record populated a global variable for the form item.
Set(varCandidate, gallerySearchResults.Selected)
Everything works as expected. Then, I changed the data source to use a stored procedure to move the search from PowerApps to SQL server. After doing so I received the error message
"Incompatible Type. We can't evaluate your formula because the context
variable types are incompatible with the types of the values in other
places in your app"
I cannot revert back to the view that was working without getting the same error. I'm hoping my only option is NOT to use a new variable and change every occurrence in the form/App. I'd like to avoid this if possible.
I cannot view the form so I'm not sure how to debug properly. My hunch is the date fields being returned via Flow are causing the problem. They are 'smalldatetime' types and the Flow is returning a string 'yyyy-mm-ddThh:mm:ss.000' even though 'date' is being requested.
"PhoneNumber": {
"type": "string"
},
"CandidateStatus": {
"type": "string"
},
"DateApplied": {
"type": "string",
"format": "date"
},
Flow JSON here does not seem to like any of the other 'date' format types.
Are there any workarounds from Flow? Should I reformat the date values when I am setting the global variable? Advice?
Turns out, I was on the right track thinking that the DATE data type coming from Flow as a string. Here's why:
A new record was created using a Patch function while setting the global variable:
Set(varCandidate, Patch('[dbo].[candidate]', Defaults('[dbo].[candidate]'), {DateApplied: DateTimeValue(Text(Now())), CreatedDate:DateTimeValue(Text(Now())), CreatedBy:varUser.Email}))
The "DateApplied" field was a "DATE" type in the SQL table and it was coming from Flow as a string "2019-03-13T17:40:52.000". The recordset from Flow was being set to the same global variable when I wanted to edit the record
Set(varCandidate, gallerySearchResults.Selected)
The error "Incompatible Type" (see question for full error message) was due to this field being a "Date Value" in a new record and a "string" in an edit record.
My fix is to remove this "Date" type fields from the patch and modify the Flow to retrieve the newly created record record by ID.
Reset everything back, including the data source, then save and close the app completely, re-test.
Remove any flow connections then save and close the app completely , re-test, then re-add the flow connections.
I don't why but PowerApps some times persist data connection errors until you have close the app down.
And just to confirm PowerApps doesn't support stored procedures as data sources, only as write using the patch function etc.
Iam new to graphql.Iam implementing a react-native app using aws appsync.Following is the code i have written in schema
type Messages {
id: ID!
createdAt: String!
updateAt: String!
text: String!
sendBy: Person!
#relation(name: "UserMessages")}
type Person {
id: ID!
createdAt: String!
updateAt: String!
name: String!
messages: [Messages!]!
#relation(name: "UserMessages")}
When i tried to query the sendBy value it is giving me an error saying
query getMessages{
getMessages(id : "a0546b5d-1faf-444c-b243-fab5e1f47d2d") {
id
text
sendBy {
name
}
}
}
{
"data": {
"getMessages": null
},
"errors": [
{
"path": [
"getMessages",
"sendBy"
],
"locations": null,
"message": "Cannot return null for non-nullable type: 'Person' within parent 'Messages' (/getMessages/sendBy)"
}
]
}
Am not understanding that error please help me.Thanks!! in Advance
This might sound silly, but still, developers do this kind of mistakes so did I. In subscription, the client can retrieve only those fields which are outputted in the mutation query. For example, if your mutation query looks like this:
mutation newMessage {
addMessage(input:{
field_1: "",
field_2: "",
field_n: "",
}){
field_1,
field_2
}
}
In the above mutation since we are outputting only field_1 & field_2. A client can retrieve the only subset of these fields.
So if in the schema, for a subscription if you have defined field_3 as required(!), and since you are not outputting field_3 in the above mutation, this will throw the error saying Cannot return null for non-nullable type: field_3.
Looks like the path [getMessages, sendBy] is resolving to a null value, and your schema definition (sendBy: Person!) says sendBy field cannot resolve to null. Please check if a resolver is attached to the field sendBy in type Messages.
If there is a resolver attached, please enable CloudWatch logs for this API (This can be done on the Settings page in Console, select ALL option). You should be able to check what the resolved Request/Response mapping was for the path [getMessages, 0, sendBy].
I encountered a similar issue while working on my setup with CloudFormation. In my particular situation I didn't configure the Projection correctly for the Global Secondary Indexes. Since the attributes weren't projected into the index, I was getting an ID in the response but null for all other values. Updating the ProjectionType to 'ALL' resolved my issue. Not to say that is the "correct" setting but for my particular implementation it was needed.
More on Global Secondary Index Projection for CloudFormation can be found here: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-dynamodb-projectionobject.html
Attributes that are copied (projected) from the source table into the index. These attributes are additions to the primary key attributes and index key attributes, which are automatically projected.
I had a similar issue.
What happened to me was a problem with an update resolver. I was updating a field that was used as GSI (Global Secondary Index). But I was not updating the GSI, so when query by GSI the index exists but the key for that attribute had changed.
If you are using Dynamo DB, you can start debugging there. You can check the item and see if you have any reference to the primary key or the indexes.
I had a similar issue.
for me the problem was lying with the return type of the schema . As i was doing a query with PK on dynamodb table ..it was returning a list of items or data you can say . but in my schema i had a schema define as a singular struct format .
Error was resolved when i just made the return type in schema as list of items .
like
type mySchema {
[ID]
}
instead of
type mySchema
{
id : ID!
name : String!
details : String!
}
This error is thrown for multiple reasons . so your reason could be else but still i just posted one of the scenarios.
I've used types before but don't know what an opaque type is. I've seen it mentioned as well. Is it better to expose an opaque type than a type alias?
Let’s answer this question by first looking at type aliases:
A type alias is fully transparent. This means that any other module importing it will have full access to its inner workings. Let’s say we’ve got a User module exposing a User type:
module User exposing User
type alias User =
{ userName : String
, age : Int
}
Anyone importing User can manipulate the data, e.g. newUser = { oldUser | age = 25 }. Or do someUser = User "Bill" 27. These manipulations are fine when you have control over the context that they exist in.
However, if User is part of a library then every change to the User type is a breaking change to people that use the library. For example, if an email field is added to User, then the constructor example (someUser = User "Bill" 27) will give a compiler error.
Even inside of a project codebase, a type alias can provide too much information to other modules which leads to code that is difficult to maintain and evolve. Perhaps a User changes drastically at some point and has a completely new set of properties. This would require changes wherever the code manipulates Users.
Opaque types are valuable because they avoid these issues. Here’s an opaque version of User:
module User exposing User
type User =
User
{ userName : String
, age : Int
}
With this version, other modules cannot access or manipulate the data directly. Often, this means you will make and expose some getter and functions:
initUser : String -> Int -> User
userName : User -> String
age : User -> String
setAge : Int -> User -> User
This is more work, but it has advantages:
Other modules only care about the User functions and don’t need to know what data is in the type
The type can be updated without breaking code outside the containing module
Much of this explanation comes from #wintvelt: elmlang.slack.com