From elephant-devel at common-lisp.net Fri Mar 9 00:09:07 2007 From: elephant-devel at common-lisp.net (elephant) Date: Fri, 09 Mar 2007 00:09:07 -0000 Subject: [elephant-ticket] #35: Remove migrate's reliance on a main-memory has to store oid-oid mappings Message-ID: <082.116fb2ec26a49a635fb017c82e9a7417@common-lisp.net> #35: Remove migrate's reliance on a main-memory has to store oid-oid mappings -------------------------+-------------------------------------------------- Reporter: ieslick | Owner: ieslick Type: enhancement | Status: new Priority: minor | Milestone: Release 0.9.0 Component: system-wide | Version: Keywords: | -------------------------+-------------------------------------------------- The current migrate facility keeps a hash of old-oid to new-objects in memory. We could store this in an index in the old database, a separate database or in the new database (and then delete it, but this interferes with the idea of migrate as psuedo-gc. -- Ticket URL: elephant elephant From elephant-devel at common-lisp.net Sun Mar 11 05:15:40 2007 From: elephant-devel at common-lisp.net (elephant) Date: Sun, 11 Mar 2007 05:15:40 -0000 Subject: [elephant-ticket] Re: #35: Remove migrate's reliance on a main-memory has to store oid-oid mappings In-Reply-To: <082.116fb2ec26a49a635fb017c82e9a7417@common-lisp.net> References: <082.116fb2ec26a49a635fb017c82e9a7417@common-lisp.net> Message-ID: <091.9cf94196bd4a4225d7b0e51ab6a8aa0e@common-lisp.net> #35: Remove migrate's reliance on a main-memory has to store oid-oid mappings --------------------------+------------------------------------------------- Reporter: ieslick | Owner: ieslick Type: enhancement | Status: closed Priority: minor | Milestone: Release 0.9.0 Component: system-wide | Version: Resolution: fixed | Keywords: --------------------------+------------------------------------------------- Changes (by ieslick): * resolution: => fixed * status: new => closed Comment: This was fixed by allowing the user to call set-oid-spec to specify an external database to use for the oid-to-oid index. The lookup fn takes an oid and classname from the oid database and calls the controller's get- cached-instance (used by the serializers) to pull the instance from the cache, or to create a semantically identical instance if it was flushed from the cache during a GC. -- Ticket URL: elephant elephant From elephant-devel at common-lisp.net Sun Mar 11 05:16:28 2007 From: elephant-devel at common-lisp.net (elephant) Date: Sun, 11 Mar 2007 05:16:28 -0000 Subject: [elephant-ticket] Re: #35: Remove migrate's reliance on a main-memory has to store oid-oid mappings In-Reply-To: <082.116fb2ec26a49a635fb017c82e9a7417@common-lisp.net> References: <082.116fb2ec26a49a635fb017c82e9a7417@common-lisp.net> Message-ID: <091.e5baa4a548c0116a54befcfc8ec576fc@common-lisp.net> #35: Remove migrate's reliance on a main-memory has to store oid-oid mappings --------------------------+------------------------------------------------- Reporter: ieslick | Owner: ieslick Type: enhancement | Status: closed Priority: minor | Milestone: Release 0.7.0 Component: system-wide | Version: Resolution: fixed | Keywords: --------------------------+------------------------------------------------- Changes (by ieslick): * milestone: Release 0.9.0 => Release 0.7.0 -- Ticket URL: elephant elephant From elephant-devel at common-lisp.net Sun Mar 11 05:32:27 2007 From: elephant-devel at common-lisp.net (elephant) Date: Sun, 11 Mar 2007 05:32:27 -0000 Subject: [elephant-ticket] Re: #9: Query Interface In-Reply-To: <082.42fd2519147aaf570309a0136a7ccff1@common-lisp.net> References: <082.42fd2519147aaf570309a0136a7ccff1@common-lisp.net> Message-ID: <091.be5ea7837bbca47ead37d4eecda7c228@common-lisp.net> #9: Query Interface --------------------------+------------------------------------------------- Reporter: ieslick | Owner: ieslick Type: enhancement | Status: assigned Priority: blocker | Milestone: Release 0.7.0 Component: system-wide | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Changes (by ieslick): * status: new => assigned -- Ticket URL: elephant elephant From elephant-devel at common-lisp.net Wed Mar 21 14:52:45 2007 From: elephant-devel at common-lisp.net (elephant) Date: Wed, 21 Mar 2007 14:52:45 -0000 Subject: [elephant-ticket] #36: map-index :start and :end tag null handling Message-ID: <082.a4a9ee7d83c903141bd73db25104414f@common-lisp.net> #36: map-index :start and :end tag null handling -------------------------+-------------------------------------------------- Reporter: ieslick | Owner: ieslick Type: defect | Status: new Priority: minor | Milestone: Release 0.7.0 Component: system-wide | Version: Keywords: indexing | -------------------------+-------------------------------------------------- There is an inconsistency in the way that nil is handled by :start and :end. Currently no keyword and a null valued keyword are treated the same, they mean the start and end of the list, respectively. However this means that the nil value itself cannot be accessed by map-index. Can map-index operate over more than numbers, strings and oids? -- Ticket URL: elephant elephant From elephant-devel at common-lisp.net Sat Mar 24 03:10:49 2007 From: elephant-devel at common-lisp.net (elephant) Date: Sat, 24 Mar 2007 03:10:49 -0000 Subject: [elephant-ticket] #37: Support complex numbers Message-ID: <082.40ccbc407c4c2a8d508540f467d4c583@common-lisp.net> #37: Support complex numbers -------------------------+-------------------------------------------------- Reporter: ieslick | Owner: ieslick Type: enhancement | Status: new Priority: minor | Milestone: Release 0.7.0 Component: serializers | Version: Keywords: | -------------------------+-------------------------------------------------- The only number type we are missing are complex numbers and these shouldn't be too hard to support. -- Ticket URL: elephant elephant From elephant-devel at common-lisp.net Sat Mar 24 03:13:09 2007 From: elephant-devel at common-lisp.net (elephant) Date: Sat, 24 Mar 2007 03:13:09 -0000 Subject: [elephant-ticket] Re: #36: map-index :start and :end tag null handling In-Reply-To: <082.a4a9ee7d83c903141bd73db25104414f@common-lisp.net> References: <082.a4a9ee7d83c903141bd73db25104414f@common-lisp.net> Message-ID: <091.d188b38715552b7859769ad175bf72cc@common-lisp.net> #36: map-index :start and :end tag null handling --------------------------+------------------------------------------------- Reporter: ieslick | Owner: ieslick Type: defect | Status: closed Priority: minor | Milestone: Component: system-wide | Version: Resolution: fixed | Keywords: indexing --------------------------+------------------------------------------------- Changes (by ieslick): * resolution: => fixed * milestone: Release 0.7.0 => * status: new => closed Comment: We decided to add a :first and :last argument that overrides the :start and :end values. This way get-instances-by-value can still map all nils. get-instances-by-range uses the null as first/last semantics, but nil nil is the same as get all. (Thanks to Henrik for the discussion on this one) -- Ticket URL: elephant elephant From elephant-devel at common-lisp.net Sun Mar 25 14:05:48 2007 From: elephant-devel at common-lisp.net (elephant) Date: Sun, 25 Mar 2007 14:05:48 -0000 Subject: [elephant-ticket] #38: Map over types Message-ID: <082.4ac3b00078224e7fbdd0dc44f6a7d0ab@common-lisp.net> #38: Map over types -------------------------+-------------------------------------------------- Reporter: ieslick | Owner: ieslick Type: enhancement | Status: new Priority: minor | Milestone: Release 0.8.0 Component: db-bdb | Version: Keywords: | -------------------------+-------------------------------------------------- Right now there is no good way to map over types is a btree or index. There are two notions of types to think about: primitive serializer types (select by type tag) or lisp types (which requires deserializing all values). The trick to lisp types is either to do a full scan with lisp subtypes, or to do a set/pset to the primitive supertype, then filter out the subtypes according to the type specifier. This might be put off until someone requests it as typically indexes are looking at ranges of Ideal implementation? Only deserialize values if primitive types match - lazy deserialization is a general feature that might be nice. -- Ticket URL: elephant elephant From elephant-devel at common-lisp.net Sun Mar 25 14:11:05 2007 From: elephant-devel at common-lisp.net (elephant) Date: Sun, 25 Mar 2007 14:11:05 -0000 Subject: [elephant-ticket] #39: Lazy deserialization Message-ID: <082.04e13479d58876b2d510777400b57f98@common-lisp.net> #39: Lazy deserialization -------------------------+-------------------------------------------------- Reporter: ieslick | Owner: ieslick Type: enhancement | Status: new Priority: minor | Milestone: Component: db-bdb | Version: Keywords: | -------------------------+-------------------------------------------------- This is a significant change, but could improve performance characteristics or make database performance design simpler. The idea is to only deserialize values if they are used, or allow partial deserialization, say to detect the type tag. This does require copying the serialized byte stream from the various pages it is stored in, but that's usually just a memcpy. This is a significant feature requiring changes to the serializer, map functions and various backend interfaces. It isn't worth it at this time as there is a workaround, which is to use lightweight persistent objects to keep references to larger values it is too expensive to deserialize, or to define derived indices which hash code or otherwise map the large datastructure to a simple range of integers or other small values. -- Ticket URL: elephant elephant From elephant-devel at common-lisp.net Sun Mar 25 14:12:15 2007 From: elephant-devel at common-lisp.net (elephant) Date: Sun, 25 Mar 2007 14:12:15 -0000 Subject: [elephant-ticket] Re: #38: Map over types In-Reply-To: <082.4ac3b00078224e7fbdd0dc44f6a7d0ab@common-lisp.net> References: <082.4ac3b00078224e7fbdd0dc44f6a7d0ab@common-lisp.net> Message-ID: <091.d966f06930a6cc1f866063687194d51f@common-lisp.net> #38: Map over types --------------------------+------------------------------------------------- Reporter: ieslick | Owner: ieslick Type: enhancement | Status: new Priority: minor | Milestone: Release 0.8.0 Component: db-bdb | Version: Resolution: | Keywords: --------------------------+------------------------------------------------- Old description: > Right now there is no good way to map over types is a btree or index. > There are two notions of types to think about: primitive serializer types > (select by type tag) or lisp types (which requires deserializing all > values). The trick to lisp types is either to do a full scan with lisp > subtypes, or to do a set/pset to the primitive supertype, then filter out > the subtypes according to the type specifier. > > This might be put off until someone requests it as typically indexes are > looking at ranges of > > Ideal implementation? Only deserialize values if primitive types match - > lazy deserialization is a general feature that might be nice. New description: Right now there is no good way to map over types is a btree or index. There are two notions of types to think about: primitive serializer types (select by type tag) or lisp types (which requires deserializing all values). The trick to lisp types is either to do a full scan with lisp subtypes, or to do a set/pset to the primitive supertype, then filter out the subtypes according to the type specifier. This might be put off until someone requests it as typically indexes are looking at ranges of Ideal implementation? Only deserialize values if primitive types match. This is a subset of the lazy deserialization feature discussed in ticket #39. -- Ticket URL: elephant elephant