SQLite

Check-in [70c84e5020]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Fix error in a comment in sqlite3session.h. No changes to code.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | sessions
Files: files | file ages | folders
SHA1: 70c84e50209722a61d66fd737e42d49275745b62
User & Date: dan 2011-07-16 18:35:53.645
Context
2011-07-18
15:22
Fix the sqlite3session_isempty() method so that it returns, as documented, non-zero when no changes have been recorded by the session object. (check-in: d04e0fd82a user: dan tags: sessions)
2011-07-16
18:35
Fix error in a comment in sqlite3session.h. No changes to code. (check-in: 70c84e5020 user: dan tags: sessions)
18:05
Note in the documentation that when iterating through a changeset, all changes to a single table are grouped together. Also add the sqlite3session_isempty() function. (check-in: 364f3b820a user: dan tags: sessions)
Changes
Unified Diff Ignore Whitespace Patch
Changes to ext/session/sqlite3session.h.
︙︙
292
293
294
295
296
297
298
299
300
301
302
303
304

305
306
307
308
309
310
311

** It is the responsibility of the caller to eventually destroy the iterator
** by passing it to [sqlite3changeset_finalize()]. The buffer containing the
** changeset (pChangeset) must remain valid until after the iterator is
** destroyed.
**
** Assuming the changeset blob was created by one of the
** [sqlite3session_changeset()], [sqlite3changeset_concat()] or
** [sqlite3changest_invert()], all changes within the changeset that apply
** to a single table are grouped together. This means that when an application
** iterates through a changeset using an iterator created by this function,
** all changes that relate to a single table are visted consecutively. There 
** is no chance that the iterator will visit a change the applies to table X, 
** then one for table Y, and then later on visit another change for table X.

*/
int sqlite3changeset_start(
  sqlite3_changeset_iter **pp,    /* OUT: New changeset iterator handle */
  int nChangeset,                 /* Size of changeset blob in bytes */
  void *pChangeset                /* Pointer to blob containing changeset */
);









|
|
|
|
|
|
>








292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312

** It is the responsibility of the caller to eventually destroy the iterator
** by passing it to [sqlite3changeset_finalize()]. The buffer containing the
** changeset (pChangeset) must remain valid until after the iterator is
** destroyed.
**
** Assuming the changeset blob was created by one of the
** [sqlite3session_changeset()], [sqlite3changeset_concat()] or
** [sqlite3changeset_invert()] functions, all changes within the changeset 
** that apply to a single table are grouped together. This means that when 
** an application iterates through a changeset using an iterator created by 
** this function, all changes that relate to a single table are visted 
** consecutively. There is no chance that the iterator will visit a change 
** the applies to table X, then one for table Y, and then later on visit 
** another change for table X.
*/
int sqlite3changeset_start(
  sqlite3_changeset_iter **pp,    /* OUT: New changeset iterator handle */
  int nChangeset,                 /* Size of changeset blob in bytes */
  void *pChangeset                /* Pointer to blob containing changeset */
);
︙︙