Hi there, me again,
I must clarify that was not in a fresh image. I've reloaded all again in a fresh image and magma has not that problem to load. I dont know yet which package conflics it.
So I'll start some usability tests...
(about half an hour later..)
ok there is something that I probably don't get here... mm let's take a second look, found it. It's in preferences.. ok the default of not seing refreshed objects when aborting is *not great* from my point of view.
Probably is too soon but I think that a couple of suggestions could be useful anyway:
*
newcomers will allways found the default behavior of #refreshPersistentObjectsEvenWhenChangedOnlyByMe in false as a strange thing. Heuristically is preferable that the default where true and to let experience make developers understand why using false can be interesting. OK re-reading the wiki now.. (to understand default) it's about the commit strategy 3, so confirming my position, IMHO is not the more intuitive one nor the first choice of a newcomer because the commit strategy 3 will be a little too creative for them. For instance aprioristically I came prepared to implement some kind of pesimistic commit unless something lighter proves to work well. With persistance I'm sure you know that you deal with conservative profiles so... making default in true will eliminate that *no show* that's my 2 cents on that. *
commit that fails because of no active txn (I mean a connected session without begin) leaves objects mutated (out of repository sync). I think that if this exception can be set in preferences to perform an abort just before signaling developers while testing and working on their stuff will love that comfortable feature so that's another eliminated *no show*. Then in production-time things can be adjusted to suite persistence imprementations without being compromised too early too much with one in particular.
In general I think that the odb's concept about easing the experience of persists the development specially smalltalk development until the point in which they reaching productivity. So if any performance should be prioritized here, I'm on the performance of the human beigns group. You allways will have to tune production stuff and machines will be faster next year, and next and next, so..
Questions (I didn't saw in FAQ):
. I know I'll probably do not implement (nor want to) it but I need to know if it's planned to support pessimistic locking somtime. . there is an idea of how many concurrent clients (sessions) can be served by a squeak image? or any other metrics relevant to measure load capacity/scalability? OK I've re-read Magma limitations, there is any news on this? . there is an idea of how much is Magma resistant to power faliures? (sata drives with software raid)
I also want to say that I found Magma concept fantastic, and a great work, I really hope it reach my needs and I'll continue my tests
thanks !
Sebastian
_____
De: magma-bounces@lists.squeakfoundation.org [mailto:magma-bounces@lists.squeakfoundation.org] En nombre de Sebastian Sastre Enviado el: Sábado, 06 de Octubre de 2007 17:32 Para: magma@lists.squeakfoundation.org Asunto: Evaluating Magma
Hi there,
I want to evaluate Magma as persistance solution for a project (on squeak and Seaside).
I'm having trouble to install it. Tried from SqueakMap and then universes. It's saying me a message about Cache is defined elesewhere.
I saw lots of packages in the squeak source repositories. I don't know how to start from there (its my favorite choice)
cheers,
Sebastian Sastre