Goods

> Hi,
>
> sorry if this is OT.
>
> i installed Goods (80) from SqueakMap. The SUnit tests failed in below
> method:
>
> KKDefaultConnection >> defaultLogin
>     ^ 'squeak', (Time millisecondClockValue hex allButFirst: 3)
>
> i added asFloat (float respondsTo: hex), but now im unsure if i missed
> some dependency package (which might change SmallInteger?). I'm
> running a 3.9b-7052 image.

> Magma
> ======
>
> Good:
> New cool query syntax (no one else has this).
> Excellent support from Chris Müller and list.
> Clean syntax
> Indexes for various classes (Dates, Strings, Numbers, etc.)
> ReadStrategies
> Native Smalltalk
> Integration package to use with Seaside.
> Bad:
> Hard to set up (the latest beta version with queries at least)
> Insert & update performance (inserting  ~260 items on a magma  
> collection takes >30'' on a single commit)
>
>
>
> GOODS
> ======
>
> Good:
> Very simple to set up
> Cleanest / less intrusive syntax of all ODBs I've seen
> Pretty fast on inserts (on my not so large data sets at least)
> Distributable / multi-language
> Bad:
> Maintained by a single guy (I'm always scared of this... what if he
>
> decides to run a restaurant?)
> Not native Smalltalk
> No indexes (must use Avi's BTree)
> No queries
>
>
> OmniBase
> ========
> Good:
> Seems to have been widely tested in several smalltalks
> Bad:
> Locking problem on Macs and Linux with Squeak has not been resolved.
>  
> Hence, if you use Squeak, Windows is the only alternative.  I've  
> tested it yesterday on my Mac and the locking issues were still  
> there.  I don't know if it is still this way under Linux.
> Ugliest syntax (for me, at least)
> No query language.
> Licencing? (don't really know about this)
>
>
> But it would be great, at least for me, to hear what others been  
> through when they decided to implement an ODB.
> Thanks
>
>
> r.

> I would just like to clarify, the Magma set up is "one-click" and
> always has been.  Ramiro was describing his experience loading the
> "queries beta" version a couple of weeks ago, which was not one-click.
> That version was finished and announced last week, it is no longer in
> beta, is therefore now a one-click install.
>
> I would also like to clarify the performance comment.  Ramiro, I
> profiled your
>
>   NYSE instance getValuesFor: 'aapl' from: ('1/1/2004' asDate) to:
> ('1/1/2006' asDate)
>
> which addeds 504 objects and would like to clarify a couple of points
> about the 33 second profile:
>
>   - 5.4 seconds was spent getting the data from Yahoo
>   - 18.1 seconds spent doing 504 queries on the MagmaSet to determine
> if the object being added already exists.  (NOTE 6 of which in
> DateAndTime>>#asUTC).
>   - 10 seconds for the actual commit
>
> MagmaSets are expensive to add to, because every object requires it to
> query to see if that object already exists.  You could use a
> MagmaCollection here and would see the time cut in half, 5.4 seconds
> for Yahoo and 10 seconds for the commmit.
>
> This is why I cringe at public declarations about performance.  One
> persons 260 objects is different than anothers.  I think the only
> meaningful way to describe or compare performance is with 1)
> well-explained execution contexts (hardware, etc.), 2) detailed
> descriptions of the task being measured, and 3) what performance-
> tuning
> considerations (which, in Magma's case, can have a 10X improvement)
> were done.
>
> MagmaBenchmarker attempts to address these items:
>
>   1) the execution context includes computer, cpu, speed, memory, and
> disk
>   2) the benchmarking methods names are descriptive in what they do
>   3) the implementation of the methods can be examined to see what
> performance tuning mechanisms were used, if any
>
> To see this output for the latest Magma:
>
>   http://minnow.cc.gatech.edu/squeak/5606
>
> I certainly don't want to proclaim Magma is blazing fast, but the
> MagmaBenchmarker on the current version just demonstrated, on my circa
> 2004 laptop, insertion of 1000 objects (100 at a time, 10 commits)  
> into
> a MagmaCollection in 4 seconds flat (5 without WriteBarrier).
>
> Understanding performance requires context, lots of context..
>
>  - Chris
>
>
>
>> Magma
>> ======
>>
>> Good:
>> New cool query syntax (no one else has this).
>> Excellent support from Chris Müller and list.
>> Clean syntax
>> Indexes for various classes (Dates, Strings, Numbers, etc.)
>> ReadStrategies
>> Native Smalltalk
>> Integration package to use with Seaside.
>> Bad:
>> Hard to set up (the latest beta version with queries at least)
>> Insert & update performance (inserting  ~260 items on a magma
>> collection takes >30'' on a single commit)
>>
>>
>>
>> GOODS
>> ======
>>
>> Good:
>> Very simple to set up
>> Cleanest / less intrusive syntax of all ODBs I've seen
>> Pretty fast on inserts (on my not so large data sets at least)
>> Distributable / multi-language
>> Bad:
>> Maintained by a single guy (I'm always scared of this... what if he
>>
>> decides to run a restaurant?)
>> Not native Smalltalk
>> No indexes (must use Avi's BTree)
>> No queries
>>
>>
>> OmniBase
>> ========
>> Good:
>> Seems to have been widely tested in several smalltalks
>> Bad:
>> Locking problem on Macs and Linux with Squeak has not been resolved.
>>
>> Hence, if you use Squeak, Windows is the only alternative.  I've
>> tested it yesterday on my Mac and the locking issues were still
>> there.  I don't know if it is still this way under Linux.
>> Ugliest syntax (for me, at least)
>> No query language.
>> Licencing? (don't really know about this)
>>
>>
>> But it would be great, at least for me, to hear what others been
>> through when they decided to implement an ODB.
>> Thanks
>>
>>
>> r.
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside