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