As some of these custom properties represent DateTime, I have also followed the documented method of 'changing field value types' to store these as DateTime as opposed to Leucine's default of FullText (so I can filter on date ranges etc)
e.g.:
This works much of the time, seemingly all the time in my local environment, but intermittently in my hosted (Azure AppService) UAT and Production environments, where I regularly see that the data type configuration has not taken after a deployment or a restart of the infrastructure. One (or more) reboots of the infrastructure is then needed to get this setting to take.
I can but assume there is some sort of race condition going on during the boot process that means that this set up is sometime honoured but sometimes not, but I've got limited debugging ability here as:
My logging is done via SeriLog and the Azure Application Insights
'sink' which hasn't been configured yet at this point in the boot
cycle so logs don't get sent
It has never failed locally, where it is easiest to add debugging code/logs etc
Has anyone else experienced this or have any ideas?
It is currently proving very irritating and means that I have to deploy updates to my clients sites out of hours at weekends etc because if/when it happens, the only solution I have found is to turn the AppService infrastructure off and then back on, leading to downtime.
Has no one else experienced this nor can see anything which differs between the code snippets above vs the Umbraco documentation?
This is a relatively straightforward implementation, basically a copy/paste job from the docs with the field/property names changed, so struggling to see where I could have strayed from the docs? Yet it continues to fail to store dateOfBirth, startDate and leaveDate as DateTime (or Ticks) in my production site after (approx) 80% of restarts or swap slots (for a release) etc making it unworkable and unfit for purpose in a clients production site.
Any input or feedback appreciated. I am currently having to get all (circa 1500) members back from the lucene query and then filter out the ones I need (at most circa 50) and then cache the results as this is offers painfully poor performance :-(
Setting Examine Indexes Data Type Set Only Working Intermittently
I store a number of custom Umbraco Member properties in the MemberIndex using the documented method of 'validating a ValueSet to see if it should be included in the index'
e.g.:
As some of these custom properties represent DateTime, I have also followed the documented method of 'changing field value types' to store these as DateTime as opposed to Leucine's default of FullText (so I can filter on date ranges etc)
e.g.:
This works much of the time, seemingly all the time in my local environment, but intermittently in my hosted (Azure AppService) UAT and Production environments, where I regularly see that the data type configuration has not taken after a deployment or a restart of the infrastructure. One (or more) reboots of the infrastructure is then needed to get this setting to take.
I can but assume there is some sort of race condition going on during the boot process that means that this set up is sometime honoured but sometimes not, but I've got limited debugging ability here as:
Has anyone else experienced this or have any ideas?
It is currently proving very irritating and means that I have to deploy updates to my clients sites out of hours at weekends etc because if/when it happens, the only solution I have found is to turn the AppService infrastructure off and then back on, leading to downtime.
Has no one else experienced this nor can see anything which differs between the code snippets above vs the Umbraco documentation?
This is a relatively straightforward implementation, basically a copy/paste job from the docs with the field/property names changed, so struggling to see where I could have strayed from the docs? Yet it continues to fail to store dateOfBirth, startDate and leaveDate as DateTime (or Ticks) in my production site after (approx) 80% of restarts or swap slots (for a release) etc making it unworkable and unfit for purpose in a clients production site.
Any input or feedback appreciated. I am currently having to get all (circa 1500) members back from the lucene query and then filter out the ones I need (at most circa 50) and then cache the results as this is offers painfully poor performance :-(
is working on a reply...