From elephant-devel at common-lisp.net  Mon Jun  9 14:52:58 2008
From: elephant-devel at common-lisp.net (elephant)
Date: Mon, 09 Jun 2008 14:52:58 -0000
Subject: [elephant-ticket] #79: Elephant transaction and cache interactions
Message-ID: <082.f5c74381cb28605c87c47affbdaa4ecd@common-lisp.net>

#79: Elephant transaction and cache interactions
---------------------+------------------------------------------------------
 Reporter:  ieslick  |       Owner:  ieslick                                     
     Type:  defect   |      Status:  new                                         
 Priority:  minor    |   Milestone:  Release 1.0 beta 2 - Testing and Performance
Component:  db-bdb   |     Version:                                              
 Keywords:           |  
---------------------+------------------------------------------------------
 Potential bug where object instances are cached in memory during a long-
 running transaction with only read locks (e.g. get-instances-by-value).
 If the transaction is aborted, the objects are cached in memory.  Is this
 a problem?

-- 
Ticket URL: <http://trac.common-lisp.net/elephant/ticket/79>
elephant <http://common-lisp.net/project/elephant>
elephant

From elephant-devel at common-lisp.net  Mon Jun  9 14:54:04 2008
From: elephant-devel at common-lisp.net (elephant)
Date: Mon, 09 Jun 2008 14:54:04 -0000
Subject: [elephant-ticket] #80: Large blob storage
Message-ID: <082.17e41994443681f2a55b9e46a2f20234@common-lisp.net>

#80: Large blob storage
-------------------------+--------------------------------------------------
 Reporter:  ieslick      |       Owner:  ieslick                                     
     Type:  defect       |      Status:  new                                         
 Priority:  minor        |   Milestone:  Release 1.0 beta 2 - Testing and Performance
Component:  serializers  |     Version:                                              
 Keywords:               |  
-------------------------+--------------------------------------------------
 Should we allow arbitrarily sized object storage?  Currently there are
 practical limits from serializer buffer size, transaction size, etc.
 Should we hack around this to chunk up long-running serializations into a
 sequence of writes?

-- 
Ticket URL: <http://trac.common-lisp.net/elephant/ticket/80>
elephant <http://common-lisp.net/project/elephant>
elephant

From elephant-devel at common-lisp.net  Wed Jun 11 17:06:24 2008
From: elephant-devel at common-lisp.net (elephant)
Date: Wed, 11 Jun 2008 17:06:24 -0000
Subject: [elephant-ticket] #81: General and Advanced OODB Features
Message-ID: <082.79237b77e5ab6b2a79055288ffcd64ac@common-lisp.net>

#81: General and Advanced OODB Features
-------------------------+--------------------------------------------------
 Reporter:  ieslick      |       Owner:  ieslick
     Type:  enhancement  |      Status:  new    
 Priority:  minor        |   Milestone:         
Component:  db-bdb       |     Version:         
 Keywords:               |  
-------------------------+--------------------------------------------------
 We may want to entertain the notion of adding some more advanced OODB
 concepts in the future:
 - Generalized value constraints (validate values at write time or at
 commit time; also hints to query system)
 - Triggers (on load/save/mutate or when satisfied constraint, call some
 function with the object instance)
 - Triggers could implement or be complemented by a declarative inter-
 object constraint system
    - o1.x is always the sum of objects in o1.assoc1
    - o1.x = (/ view.width 2)

 This is a nice example reference:
 http://citeseer.ist.psu.edu/cache/papers/cs/1341/ftp:zSzzSzftp.research.att
 .comzSzdistzSzdbzSzatt-db-92-10.pdf/jagadish92integrity.pdf

-- 
Ticket URL: <http://trac.common-lisp.net/elephant/ticket/81>
elephant <http://common-lisp.net/project/elephant>
elephant