Evaluating Magma

[Sebastian Sastre]

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 at lists.squeakfoundation.org
[mailto:magma-bounces at lists.squeakfoundation.org] En nombre de Sebastian
Sastre
Enviado el: Sábado, 06 de Octubre de 2007 17:32
Para: magma at 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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20071007/b08519fa/attachment.htm