vcache 0.2.2 → 0.2.3

raw patch · 4 files changed

+22/−24 lines, 4 files

Files

• hsrc_lib/Database/VCache/Path.hs +13/−21
• hsrc_lib/Database/VCache/VGet.hs +6/−0
• hsrc_lib/Database/VCache/VTx.hs +2/−2
• vcache.cabal +1/−1

@@ -11,28 +11,20 @@ maxPathLen :: Int maxPathLen = 511  -- key size limit from LMDB 0.9.10 --- | VCache implements a simplified filesystem metaphor. Developers --- can assign a distinct prefix for all PVars created by the VCache,--- thus modeling namespaces or subdirectories. Assuming the normal --- advice of opening the VCache only once in the main module, these--- prefixes enable transparent, modular decomposition of a VCache --- application without risk of name collisions.------ VCache is simplistic about this: a prefix is appended directly.--- If developers use subdir "foo" followed by "bar", the result is --- the same as "foobar". Separators are left to local conventions.--- Consider "foo/" and "bar/" to model filesystem subdirectories. ---                 --- Paths have a limited maximum size of ~500 bytes, including the--- final PVar name. A runtime error may be generated for oversized--- paths. In practice, this should not be an issue. +-- | VCache implements a simplified filesystem metaphor. By assigning+-- a different prefix for root PVars loaded by different subprograms,+-- developers can guard against namespace collisions. Each component+-- may have its own persistent roots.+-- +-- While I call it a subdirectory, it really is just a prefix. Using+-- "foo" followed by "bar" is equivalent to using "foobar". Developers+-- should include their own separators if they expect them, i.e. "foo\/"+-- and "bar\/". ----- Usage Note: Subdirectories allow developers to control risk of--- namespace collisions between modules or plugins. But they are not--- intended for domain data! Avoid dynamically creating directories--- or named PVars based on runtime data. It's better to push most--- domain logic and schema into the PVar layer, which is subject to--- rich type safety, GC, potential versioning, and other benefits.+-- Paths are limited to ~500 bytes. For normal use, this limit will not+-- be a problem. If you're creating PVars based on runtime inputs, those+-- should always be dynamic PVars. Root PVar names should never be much +-- larger than fully qualified function names. -- vcacheSubdir :: ByteString -> VCache -> VCache vcacheSubdir p (VCache vs d) = 

@@ -5,6 +5,7 @@      -- * Prim Readers     , getVRef, getPVar+    , getVSpace     , getWord8     , getWord16le, getWord16be     , getWord32le, getWord32be@@ -116,6 +117,11 @@             return (VGetR pvar s')         _ -> return (VGetE "getPVar") {-# INLINABLE getPVar #-}++-- | Read the VSpace. This value is constant for a full VGet operation.+getVSpace :: VGet VSpace +getVSpace = VGet $ \ s -> return (VGetR (vget_space s) s)+{-# INLINE getVSpace #-}  -- | Read words of size 16, 32, or 64 in little-endian or big-endian. getWord16le, getWord16be :: VGet Word16

@@ -38,8 +38,8 @@     let wsync' = updateSync bSync mvWait (write_sync w) in     let w' = Writes { write_data = wdata', write_sync = wsync' } in     writeTVar (vcache_writes vc) w' >>= \ () ->-    return $ w' `seq` do-        signalWriter vc +    return $ do+        w' `seq` signalWriter vc          when bSync (takeMVar mvWait)         return r 

@@ -1,5 +1,5 @@ Name: vcache-Version: 0.2.2+Version: 0.2.3 Synopsis: large, persistent, memcached values and structure sharing for Haskell  Category: Database Description: