Persistent arrays
in [Lisp]
|
From: Alex Mizrahi on 29 Mar 2010 17:12 ??>> I've made one for the purpose of comparison. ??>> Here's how it looks like: ??>> ??>> (open-store #p"my.store") ??>> ??>> (defvar *myarray* (make-persistent-array '*myarray* '(2 2))) JUR> This functions leads me to think that your persistence layer JUR> uses a strategy different from cl-prevalence. Strategy is dictated by use. You can't allow persistent layer to define nature of your application and the way you work with your data. It's the other way around. Slobodan's description made me think about exploratory programming (where you work with these arrays in REL) and heavy mathematical functions. (I'm speaking about applications I was working with some time ago.) This means that: * persistence should be transparent * you need to serialize data, not calls which produce that data, because computations might be very lengthy But, you see, it wasn't that hard to make wrapper on top of cl-prevalence to make API style I want, and I can't say it was using cl-prevalence in totally unnatural way -- more like it cut unneeded flexibilty and provided less verbose, fancy API this way. JUR>>> How does the system know which objects to persist? ??>> ??>> Instances of ele:btree and JUR> As I said earlier, not deriving from a special "persistence" base JUR> class is exactly the interesting bit about cl-prevalence, you can JUR> persist any value, also integer and cons. You cannot just persist any value, it needs to be referenced in some way, accessible from the root object, directly or indirectly. Otherwise, how can you reach that value you have persisted? It is absolutely same in Elephant -- you can persist intergers and conses, but they should be referenced from root object, directly or indirectly. ??>> Either one operation of (setf get-value), or you can do it manually: ??>> ??>> (with-transaction () ??>> (setf (get-value 5 *my-array*) 5.0) ??>> (setf (get-value '(3 4) *my-array*) 5.0)) ??>> ??>> By the way, it also supports multi-threading and isolation. JUR> So you need to to do a bit more than just setf. What a surprise. No, you don't. You only need with-transaction if you want some group of setfs to be in transaction. Otherwise, naked setfs are ok. ??>> But you said before (you or Raffael, I don't remember who said what ??>> exactly) that cl-prevalence is totally unobtrusive, so you can keep ??>> all your code and add persistence in some "automatic" way. JUR> No, didn't say that. Your words: "You dont in fact have to write it out either, rather you have to think of changing the data as a transaction, where the transaction is a function." So it is enough only to "think" about it? Or maybe one needs to write considerable amounts of code to get functions logged, and also rearrange existing code to make it prevalence-compatible. (E.g. you can't just pass a reference to a part of compound object into a transaction function, you have to use "navigation" instead.) "So instead of just changing the data, you have a function which represents the change. For instance change-customer-name or add customer. These functions are instrumented by the prevalence system, but for the user it is automatic." Maybe it's just a bad phrasing, but I can't read it in any other way than to think that cl-prevalence somehow instruments code automatically so programmer doesn't have to. As I understand, the only thing which cl-prevalence does automatically is replaying transactions, the rest is exactly as it is written, nothing automatic. In both these paragraphs it looks like you were trying to downplay difficulties of working with cl-prevalence. (And in my opinion cl-prevalence is much more difficult to deal with than, for example, Elephant and CLSQL.) Now let's check what Raffael wrote: "You seem to be missing the point of the whole in-memory thing - that you don't need an extra layer on top of your existing code because the in-memory data *is* the database. You just need to add transactions (if you need them) and persistence. cl-prevalence adds both of these." Excuse me, what is all that execute-transaction stuff if it is not an "extra layer on top of your existing code"? If code needs to be heavily instrumented, I'd call stuff it is instrumented with a layer. JUR>>> (defun tx-array-change-element (system index1 index2 new-value) JUR>>> (let ((array (cl-prevalence:get-root-object system :array))) JUR>>> (setf (aref array index1 index2) new-value))) ??>> That's pretty verbose, don't you think so? JUR> Not really. If it is not verbose, then I don't know what is... It is maybe 5 times more verbose than naked (setf aref) which is essentially what all this code does. ??>> I'm just asking you guys to be more honest in your propaganda JUR> This is usenet. Well, sure -- you post a bit dishonest information, I post rebuttal with code examples -- so what's the problem? ??>> -- don't ??>> forget to mention that cl-prevalence requires considerable changes to ??>> code to add persistence. JUR> It doesn't. So, (defun tx-array-change-element (system index1 index2 new-value) (let ((array (cl-prevalence:get-root-object system :array))) (setf (aref array index1 index2) new-value))) .... (execute-transaction(tx-array-change-element *system* index1 index2 new-value) in place of (setf (aref array index1 index2) new-value) is not a considerable change? Ok. Just an order of magnitute more verbose, but otherwise it is unnoticeable. ??>> Each persistence solution is a trade-off. Lack of support for "ten ??>> million objects" is not the only weak part of cl-prevalence -- it ??>> totally lack query language, requires code instrumentation etc. JUR> It uses CL as a query language. Do you know what is "managed prevalence"? There was some reason behind "managed prevalence", wasn't there? But this "managed prevalence" only implements very basic object indexing, without support for range queries and ordered iteration. ??>> I don't want people to rely on desinformation too. You and especially ??>> Raffael paint other persistence solutions as heavy-weight and ??>> cumbersome, JUR> I talked only about SQL databases, in comparison with cl-prevalence. There are libraries (e.g. CLSQL) which implement object-relational-mapping and provide lispy query languages. With them SQL isn't as unpleasant as it used to be. JUR> I hope you will not misrepresent cl-prevalence too badly. Well, if you want, you can help writing cl-prevalence version of it (I've got somewhat bored of it already), and also we can discuss how to organize examples so they fit different strategies well. But these examples should be of CRUD (create-read-update-delete) style -- thing which SQL databases are designed to do well.
From: Johan Ur Riise on 29 Mar 2010 18:42
"Alex Mizrahi" <udodenko(a)users.sourceforge.net> writes: JUR Alex > > ??>> I'm just asking you guys to be more honest in your propaganda > JUR> This is usenet. > > Well, sure -- you post a bit dishonest information, I post rebuttal > with code examples -- so what's the problem? It's more like you posted a bit of desinformation, I put it right, so what is the problem. |