We can define a parameter that is required and nullable in Flutter version 2, does it make sense? Why should we have a required parameter which accepts null?
In terms of database values like in SQL, NULL specifically refers to a "missing" value. In other words it references a value that could or will be defined but has not (yet) been.
To answer your question, it depends on what the field is and whether or not it's being stored in any kind of state, whether that state is front or back end.
One example where I would consider using a nullable but required field would be if I'm soft deleting records and am marking a deleted_at column. I want to require this field for a soft delete, but it is expected to not be defined until an actual delete occurs, whenever that is.
Flutter is basically a data-driven UI that should have one UI page for any given state. So if you, say, had a user record that was soft deletable on the backend and a profile user page that might be shown (to an admin or whatever), you might want to set the deleted_at field in the Dart code to be required but nullable to distinguish the state of a soft deletable user record.
Related
I created a custom work item type (WIT) and I added a field of type integer for usage as unique identifier. It is called ID and is a required field.
I would like the following constraint:
When a user creates a new work item of this type and inserts a value for ID, a check is run to verify that there is no work item of this type that already has the same ID. If so the user should be prevented from creating the work item.
The point is to avoid having multiple work items of this type with duplicate unique IDs. I looked into the "Rules" section to see if I could add a constraint to check for pre-existing integers of the same value, and prevent the user from creating the WIT if it already exists in the system. However I was not able to find a way to do so. I also tried making the field of type identifier but that just forces you to user a person (not number) as an identifier.
Your goals are not clear in your question. You already have ID (or System.Id as system reference) for each work item type. You do not need to create something new. Rules in work items types do not support complex logic (Sample custom rule scenarios).
As a workaround (if you need the second id for your work item type), you can:
Set default value 0 for your field.
Create a custom app to:
Find 0 ids: Query By Wiql.
Updated them to the calculated value: Work Items - Update.
I have an app with an entity Order with a field Status. The values of the Status is "related to" an entity Status in the admin module which contains one field with values : Shipped, Resolved, Cancelled, On hold, Disputed, In Process.
Is it possible to define these values in the nps script ?
No. It's not if you use a field "related to". You must fill in form of entity status to provide values you want.
If you want your drop down list to rely on values that you write in your script, you must use "enum" type.
add field Status with type enum and values Shipped, Resolved, Cancelled, On hold, Disputed, In Process
But this way, you won't benefit from status component features.
I use Hibernate with Envers and have an entity with some columns annotated with #Audited(withModifiedFlag = true), i.e. there is an additional boolean column in the _AUD table that indicates if the column was updated or not.
If I save a new entity, a corresponding entry is written in the _AUD table with revtype 0. I have a problem with the _MOD colum value. If the column is null the value of the _MOD entry is false and if there is a non-null value the _MOD entry is true. I think for a new entry (i.e. revtype=0) it's more logical to have all _MOD values set to false since the columns haven't been modified. Is there a way to achieve that?
The main reason those _MOD fields end up being set for values that are inserted initially is because all of the prior entity state is null and those comparisons yield differences (e.g. non-null != null) and therefore its seen as having been modified. The feature does not take into account whether the operation being performed is an INSERT, UPDATE, or a DELETE.
Personally, I find the current behavior more logical.
For that initial ADD operation, changing the behavior will force you to have some branch logic to deal with seed value changes based on revision number of revision type where-as simply using the _MOD field behavior as it is today implies you can simply ignore the revision type/number and just use the toggles on any query.
Unfortunately you cannot toggle this behavior presently.
We could look at adding a configuration parameter that would allow you to influence whether the ADD operation should be treated as a modification or not. If its something that you and others find useful, please feel free to open a JIRA here.
In CRM, when I'm, trying to set up a work flow, I get to choose the timeout to be related to a certain entity's creation time. There are three fields to relate to.
Record Created On
Created On
Modified On
While the last one is very obvious, I can't see any logical difference between the two others.
The difference is that Created On (createdon) is filled out automatcally by the server when you actually create the record, while Record Created On (overriddencreatedon) will usually be null (unless the record was imported into CRM and you chose to explicitly override the record creation date to match when it was created in another system).
You should use the first and skip the latter, as it's not supported (as far I've got it right when I talked to a MVP about it). Why it show, she had no idea and neither do I. Maybe #JamesWood has a shot. He usually does. (sucking-up in progress)
I've never used the latter and I believe you'll keep your hair off-grey and on-head if you stick to the same approach.
From the SDK:
The createdon attribute specifies the date and time that the record was created. To import data in the createdon attribute, map the source column that contains this data to the overriddencreatedon attribute.
During import, the record’s createdon attribute is updated with the value that was mapped to the overriddencreatedon attribute and the overriddencreatedon attribute is set to the date and time that the data was imported.
If no source value is mapped to the overriddencreatedon attribute, the createdon attribute is set to the date and time that the data was imported and the overriddencreatedon attribute is not set to any value.
Link to BlogSpot
Link to Social MSDN
Here is my issue. I am currently forced to use Access and I am writing some generic validation that I can add to forms.
It was all going well and catching empty fields in form_error based on the error "You tried to assign the Null value to a variable that is not a Varient data type"
All of my required varchar fields are NOT NULL.
Unfortunately if a textbox has a control source to a large varchar DB field it behaves differently. I can't remember the size threshold but assume this behaviour difference would be equivalent to text vs. memo in an access table).
Basically, if you delete the contents of a small text box control it attempts to write null and the error is caught. All good.
If you do the same on a text box linked to a larger varchar, or memo database field then it writes a blank string which is considered valid.
I have confirmed this by changing the db Schema between varchar(50) and varchar(256), updating the linked table in Access and restarting Access for good measure.
I am hoping someone can point me to a property to set or some tiny piece of generic code that can be added to make all text boxes behave the same regarding writing NULL/Empty string when they are empty regardless of the size of the DB field they are connected to.
Just to note that also the box behaves differently on insert or edit. If not filled on insert it does leave the DB entry as null.
That's pretty much the way you have to do it. You could set up a "Validation Rule" on each text field, but again that would require hunting down all the text controls.
You can make that job easier. If you check the Object Dependencies of the tables, you can get a list of all the forms (and queries, etc.) involved. Then you can be sure you have hit each one.