Login
Changes To DbFunctions
Login

Changes to "DbFunctions" between 2014-02-14 15:40:08 and 2014-03-18 16:02:27

45
46
47
48
49
50
51














52
53
54
55
56
57
58
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72







+
+
+
+
+
+
+
+
+
+
+
+
+
+







SELECT DISTINCT(fsl_dirpart(name)) n
FROM filename WHERE n IS NOT NULL
ORDER BY n
</pre></nowiki>

To get all the dirs for a specific version one needs to do more work. We'll leave that as an exercise for... me, and once i figure it out i'll post it. It seems that getting that information requires C-level code for the time being.

<h3>FSL_IS_ENQUEUED() and FSL_IF_ENQUEUED()</h3>

<tt>FSL_IS_ENQUEUED(INT)</tt> determines whether a given file is "enqueued" in a pending checkin operation. This is normally only used internally, but "might" have some uses elsewhere. If no files have explicitly been queued up for checkin (via the <tt>fsl_checkin_file_enqueue()</tt> C function) then <em>all files</em> are considered to be selected (though only <em>modified</em> files would actually be checked in if a commit were made).

As its argument it expects a <tt>vfile.id</tt> field value (vfile is the table where fossil tracks the current checkout's status). It returns a truthy value if that file is selected/enqueued, else a falsy value.

<tt>FSL_IS_ENQUEUED(INT,X,Y)</tt> is a close counterpart of <tt>FSL_IS_ENQUEUED()</tt>. If the <tt>vfile.id</tt> passes as the first parameter is enqueued then it resolves to the <tt>X</tt> value, else to the <tt>Y</tt> value, <em>unless</em> Y is NULL, in which case it always resolves to X. Why? Because its only intended usage is to be passed the (id, pathname, origname) fields from the vfile table.


<tt>FSL_IS_ENQUEUED(I,X,Y)</tt> is basically equivalent to this pseudocode:

<nowiki><pre>
result = FSL_IS_ENQUEUED(I) ? X : (Y IS NULL ? X : Y)
</pre></nowiki>

<h3>FSL_J2U()</h3>

<tt>FSL_J2U(JULIAN_DAY)</tt> expects a Julian Day value and returns its equivalent in Unix Epoch timestamp as a 64-bit integer, as per <tt>fsl_julian_to_unix()</tt>. Fossil tends to use Julian Days for recording timestamps, but a small few cases use Unix timestamps.


<h3>FSL_SYM2RID()</h3>