check InodeCache in inAnnex et al

This avoids querying the database when the content file doen't exist
(or otherwise fails the provided check). However, it does add overhead of
querying the database, and will certianly impact performance.
This commit is contained in:
Joey Hess 2015-12-10 14:51:04 -04:00
parent 2b8f6b8b2f
commit f80a3d8cd0
Failed to extract signature
2 changed files with 18 additions and 10 deletions

View file

@ -84,7 +84,10 @@ inAnnex key = inAnnexCheck key $ liftIO . doesFileExist
inAnnexCheck :: Key -> (FilePath -> Annex Bool) -> Annex Bool
inAnnexCheck key check = inAnnex' id False check key
{- Generic inAnnex, handling both indirect and direct mode.
{- inAnnex that performs an arbitrary check of the key's content.
-
- When the content is unlocked, it must also be unmodified, or the bad
- value will be returned.
-
- In direct mode, at least one of the associated files must pass the
- check. Additionally, the file must be unmodified.
@ -93,9 +96,17 @@ inAnnex' :: (a -> Bool) -> a -> (FilePath -> Annex a) -> Key -> Annex a
inAnnex' isgood bad check key = withObjectLoc key checkindirect checkdirect
where
checkindirect loc = do
whenM (fromRepo Git.repoIsUrl) $
error "inAnnex cannot check remote repo"
check loc
r <- check loc
if isgood r
then do
cache <- Database.Keys.getInodeCaches key
if null cache
then return r
else ifM (sameInodeCache loc cache)
( return r
, return bad
)
else return bad
checkdirect [] = return bad
checkdirect (loc:locs) = do
r <- check loc

View file

@ -325,14 +325,11 @@ files to be unlocked, while the indirect upgrades don't touch the files.
#### implementation todo list
* inAnnex check should fail in the case where an annexed object is unlocked
and has had its content changed. Could use an InodeCache for
such objects. This parallels how inAnnex checks work for direct mode.
* Reconcile staged changes into the associated files database, whenever
the database is queried.
* See if the cases where the associated files database is not used can be
optimised. Eg, if the associated files database doesn't exist at all,
we know smudge/clean are not used, so queries for associated files don't
* See if the cases where the Keys database is not used can be
optimised. Eg, if the Keys database doesn't exist at all,
we know smudge/clean are not used, so queries don't
need to open the database or do reconciliation, but can simply return none.
Also, no need for Backend.lookupFile to catKeyFile in this case
(when not in direct mode).