I am trying to save a null value in a dateTimeField object in MongoDB. I have a date I only want set after a certain condition has been fulfilled, but my site has the ability to save an object multiple time to the database before this variable will be set to anything other than a null or empty string value. I tried using db.dateTimeField(null=True) in my model file per Mongo's documentation to save a null value, but I still get an error when trying to save to the database.
According to this issue on Github, there is some inconsistent behavior with setting null values to dateTimeFields. Does anyone know if this has been fixed? I have a work around (adding my attribute to my object, then assigning it a value right before saving, therefore bypassing the need to save a null value, but it is a bit hacky, and I would like to use MongoDB's built in functionality if possible).
Thanks in advance!
Related
I am currently in the process of migrating my flutter app to null safety. I came across the following question:
I have a DatabaseService which should create an entry in my firebase. One of the fields is a reportedDate DateTime field which was so far always "null" upon initial creation of the entry since it represents the date a user reported the entry as faulty which is obviously not the case once its initially created.
How do I handle this now in null safe environment? Do I simply change my DatabaseService to not write the "reportedDate" initially Or is there another option to initialize the field?
Thanks
Trying to sync up a postgres record to airtable on create/update. The field has a couple of ids that I would like to check for in airtable to determine whether I should create a new record or update an existing one. The first id (optional_id) I need to search on can possibly be null. This causes the search to fail before it can get to the other id(required_id) that should always be populated. Is there any way I can skip the initial search for optional_id if it turns out to be null in postgres?
My current outline is as follows:
I would use a Formatter > Text > Default Value step in case the input value can be null and then make sure the fallback value is from a record that does not exist.
If further help is needed, feel free to reach out to us here:
https://zapier.com/app/get-help
I have a question regarding best practices to insert Documents in MongoDb.
In my data source the key "myData2" can be null or a string. Should I add "myData2" as null to my database or is it better to leave the value out if not defined? What is the "clean" way to deal with this?
[{
"myData1": "Stuff",
"myData2": null
}]
Since MongoDB permits fields to be added to documents at any time, most (production) applications are written to handle both of the following cases:
A new field is added to the code, but the existing data doesn't have it, and it needs to be added over time to the existing data either on demand or as a background process
A field is no longer used by the code but still contains values in the database
What would your application do if the field is missing, as opposed to if it's set to the null value? If it would do the same thing, then I suggest not setting fields to null values for two reasons:
It streamlines the code because you only need to handle one possibility (missing field) on the reading side, instead of two (field missing or null)
It requires less storage space in the database.
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.
We are saving more than one entity type in one unit of work. There are many DateTime fields in each entity-type. Sometimes, an SqlDateTime overflow exception occurs because a DateTime field is not initialized.
To find the field/property that causes the problem is an annoying task. Does anybody know a debugging technique to find out which field is causing the problem? To check every field is cumbersome.
Thanks a lot for hints.
If you're using the DateTime? nullable type then you can use the property hasValue to check if it is null. If you're using DateTime then I believe it defaults to the min value which is DateTime.MinValue and can be easily checked. The MinValue is something insane like the year Jan 1st 0001, so it makes sense that SQL wouldn't like that
If you're taking something out of the db, then a standard null check works fine.