Thanks for the great video! Why is it necessary to have the cf field? For example couldn't getAllCurrent() just retrieve all rows that have a null ared? (ared being indexed of course)?
Thanks again for a very good video. I have a question though and wanted to check my understanding around the usage of fields cf (change flag), df (delete flag) and ared. Is it safe to state that the following sets of cf:df:ared values will always mean that we are looking at the latest version of a particular record: 0:0:non-null, 1:0:null and 0:1:non-null?
The cf flag and the ared should always be in sync (cf = 1, ared = null, cf = 0, ared = timestamp of end date). The df flag stands alone.. It has been a bit since I reviewed the API logic but I am pretty sure your current record can be marked as deleted, so cf =1, ared = null, df = 1 would be possible.
Thanks for the great video! Why is it necessary to have the cf field? For example couldn't getAllCurrent() just retrieve all rows that have a null ared? (ared being indexed of course)?
Yes, the cf is largely redundant.. It can be faster to index on to speed up queries
Thanks!
Thanks again for a very good video. I have a question though and wanted to check my understanding around the usage of fields cf (change flag), df (delete flag) and ared. Is it safe to state that the following sets of cf:df:ared values will always mean that we are looking at the latest version of a particular record: 0:0:non-null, 1:0:null and 0:1:non-null?
The cf flag and the ared should always be in sync (cf = 1, ared = null, cf = 0, ared = timestamp of end date). The df flag stands alone.. It has been a bit since I reviewed the API logic but I am pretty sure your current record can be marked as deleted, so cf =1, ared = null, df = 1 would be possible.
@@CodingCoach Thanks. I think I confused myself with "cf" as "Change Flag"....but instead it is "Current Flag". Now it makes sense.