> I haven't had a chance to play with your code yet but at first glance > it looks good. Does the above mean that all set operations are > automatically supported and the accelerated?
Unfortunately not for all operations. For example, clojure.set/join uses its own index function, which builds an index for every join invokation. On the other hand, difference, union and intersection use the primary-key index (through .equals), which may be a bit faster than hashing whole tuples. > Do you think it is possible to implement join/union etc so that they > produce lazy relations (or just lazy-seq of rows)? That would be very > useful in many common use cases (instead of cursors). I tried it once, but I was too ambigious. Providing lazy relations and hiding the implementation details (SQL or clojure) while wrapping it in a relational algebra API just didn't work out to be practical :). Maybe that snippet is a good foundation to start a more humble approach. But with clojure you get already a general-purpose, lazy select and project operations (filter and map). Adding lazy joins and set-operations isn't that hard. Making them efficient beyond basic index usage is harder. > As for the storage persistence - that's a low priority (at least for > me), but it would be good to have at least some method for tying a > relation to such storage (like a "tie" function in Perl). > Can you tell me more about these hooks to Clojure STM and Cells? Currently, there are no Hooks, and Cells are just an idea: http://www.assembla.com/wiki/show/clojure/Cells http://groups.google.com/group/clojure/browse_thread/thread/aa22a709501a64ac Erik -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
