Merge lp:~thisfred/u1db/indexing-deleted-docs into lp:u1db
| Status: | Merged |
|---|---|
| Approved by: | Eric Casteleijn on 2012-04-24 |
| Approved revision: | 253 |
| Merged at revision: | 253 |
| Proposed branch: | lp:~thisfred/u1db/indexing-deleted-docs |
| Merge into: | lp:u1db |
| Diff against target: |
96 lines (+25/-5) 4 files modified
src/u1db_query.c (+9/-1) u1db/backends/inmemory.py (+2/-1) u1db/backends/sqlite_backend.py (+2/-0) u1db/tests/test_backends.py (+12/-3) |
| To merge this branch: | bzr merge lp:~thisfred/u1db/indexing-deleted-docs |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| John A Meinel (community) | 2012-04-23 | Approve on 2012-04-24 | |
|
Review via email:
|
|||
Commit Message
Adding a new index to a database that contains deleted documents no longer breaks.
Description of the Change
Adding a new index to a database that contains deleted documents no longer breaks.
| John A Meinel (jameinel) wrote : | # |
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 4/23/2012 10:09 PM, Eric Casteleijn wrote:
> Eric Casteleijn has proposed merging
> lp:~thisfred/u1db/indexing-deleted-docs into lp:u1db.
>
> Requested reviews: Ubuntu One hackers (ubuntuone-hackers)
>
> For more details, see:
> https:/
>
> Adding a new index to a database that contains deleted documents
> no longer breaks.
review: approve
With the small tweak of fixing the comment on why we are continuing.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk+
FB0An3dd/
=X70+
-----END PGP SIGNATURE-----
| Eric Casteleijn (thisfred) wrote : | # |
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 4/23/2012 10:09 PM, Eric Casteleijn wrote:
> > Eric Casteleijn has proposed merging
> > lp:~thisfred/u1db/indexing-deleted-docs into lp:u1db.
> >
> > Requested reviews: Ubuntu One hackers (ubuntuone-hackers)
> >
> > For more details, see:
> > https:/
> docs/+merge/103165
> >
> > Adding a new index to a database that contains deleted documents
> > no longer breaks.
>
> Nice catch on this. Though I'm not sure about your solution.
>
> + if (context.content == NULL)
> + {
> + // Invalid JSON in the database, for now we just continue?
> + status = sqlite3_
> + continue;
> + }
>
> I think this should instead be:
>
> if (context.content == NULL) {
> // Deleted document, just skip it and onto the next
> continue;
> }
I'm not sure I understand:
The while loop will never advance to the next table row if we just do continue without the
status = sqlite3_
unless we advance the row in the while statement itself, this would result in an infinite loop? Maybe I'm reading the code wrong.
> And this one:
>
> if (context.obj == NULL
> || !json_object_
> {
> // Invalid JSON in the database, for now we just continue?
> + status = sqlite3_
> continue;
> }
>
> Should probably actually be an error, rather than just continuing. I
> think I was just cutting corners because we didn't need it for
> compatibility with the test suite.
Yes, now that we catch the case of the deleted document, this should probably be an error.
> So I think your change is ok here, but we need a test for this case. I
> suppose it is arguable. Should we skip (because creating an index
> isn't a great time to just fail because you have bad data), or should
> we fail (so that you know early your content is incorrect.)
I'll file a bug and think about a good test case, and how to handle the case of corrupted content in general. Since it's not easy (hopefully) to get invalid JSON into the db using our API, I think we should probably make it break as early and explicitly as possible.
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
...
>> I think this should instead be:
>>
>> if (context.content == NULL) { // Deleted document, just skip it
>> and onto the next continue; }
>
>
> I'm not sure I understand:
>
> The while loop will never advance to the next table row if we just
> do continue without the
>
> status = sqlite3_
>
> unless we advance the row in the while statement itself, this would
> result in an infinite loop? Maybe I'm reading the code wrong.
>
Sorry, I'm not saying you shouldn't step, just fix the comment.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk+
KncAn1HZEXxVqXK
=fb/Y
-----END PGP SIGNATURE-----
- 254. By Eric Casteleijn on 2012-04-24
-
comments improved.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 4/23/2012 10:09 PM, Eric Casteleijn wrote: /code.launchpad .net/~thisfred/ u1db/indexing- deleted- docs/+merge/ 103165
> Eric Casteleijn has proposed merging
> lp:~thisfred/u1db/indexing-deleted-docs into lp:u1db.
>
> Requested reviews: Ubuntu One hackers (ubuntuone-hackers)
>
> For more details, see:
> https:/
>
> Adding a new index to a database that contains deleted documents
> no longer breaks.
Nice catch on this. Though I'm not sure about your solution.
+ if (context.content == NULL) step(statement) ;
+ {
+ // Invalid JSON in the database, for now we just continue?
+ status = sqlite3_
+ continue;
+ }
I think this should instead be:
if (context.content == NULL) {
// Deleted document, just skip it and onto the next
continue;
}
And this one:
if (context.obj == NULL is_type( context. obj, json_type_object)) step(statement) ;
continue;
|| !json_object_
{
// Invalid JSON in the database, for now we just continue?
+ status = sqlite3_
}
Should probably actually be an error, rather than just continuing. I
think I was just cutting corners because we didn't need it for
compatibility with the test suite.
So I think your change is ok here, but we need a test for this case. I
suppose it is arguable. Should we skip (because creating an index
isn't a great time to just fail because you have bad data), or should
we fail (so that you know early your content is incorrect.)
John
=:->
-----BEGIN PGP SIGNATURE----- enigmail. mozdev. org/
WlX0ACgkQJdeBCY SNAAMgfACfbWefq MJBiDvuvAKjUmkd RYM1 LpDh2o0BUVpH9bk du
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk+
/YYAn232RCIBxvG
=WeJf
-----END PGP SIGNATURE-----