I definitely second this suggestion. We have recently being working on a
binary store for dense data we would like to access as if they were
properties of nodes. Right now we have properties that are references to
files on disk, and then handle the binary ourselves, but this does not
benefit from any transactional advantages. Rick's suggestion of a plugable
store would suite us very well, because I presume Neo4j would specify the
interface/api to use to implement such a store in a way that could be
handled atomically within transactions, and then we could satisfy that with
our own store.

On Wed, Dec 7, 2011 at 3:43 PM, Rick Bullotta
<rick.bullo...@thingworx.com>wrote:

> One area where I would love to see the Neo4J team focus some energy is in
> the efficient storage and retrieval of blob/large text properties.  Similar
> to the indexing strategy in Neo4J, it would be nice if this was pluggable
> (and it could depend on some other data store more optimized for blob/clob
> properties).
>
> The keys for this to be successful are:
>
> - Transacted
> - Does not store these properties "in memory" except when accessed (and
> then, perhaps offer a getPropertyAsStream method and a
> setPropertyFromStream method for optimal performance)
> - Transparent - should just "work"
>
> Nice to haves, but not at all required in the first iteration:
>
> - Pluggable (store in Neo4J native, filesystem, EC2 simple storage, etc.)
>
> Addition of these capabilities would move Neo4J into a dramatically
> expanded realm of potential applications, some of which are quite mind
> blowing, both in the social realm and in the enterprise realm.
>
> Feedback welcomed!
> _______________________________________________
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to