MagmaCollectionReader behavior

[Miguel Cobá]

On Wed, Apr 1, 2009 at 10:53 AM, Miguel Cobá <miguel.coba at gmail.com> wrote:
> 2009/4/1 Chris Muller <ma.chris.m at gmail.com>:
>> Hi again!  I'd just like to say one more thing; In Smalltalk, Strings
>> do not have any upper-bound size-limit, so they are as flexible as a
>> CLOBS in a RDBMS.  The premise of your indexing comparison would seem
>> require an RDBMS to index and search entire CLOB values, which I don't
>> think they can do without application-developer help.  (Please correct
>> me if I'm wrong, I haven't used RDBMS in years..)
>
> Oh, yes, that explains the problem. I was comparing a string in
> Smalltalk to a varchar with a fixed lenght.
> And indeed, reading the documentation for indexes on MySQL, for
> example, the index creation over text fields (blobs alike for strings)
> *requires* a index prefix to create the index. Something analogous to
> the MagmaIndexes for strings.

I forgot the link to the MySQL documentation of indexes:

http://dev.mysql.com/doc/refman/5.0/en/indexes.html

>
>>
>> OTOH, if you define a indexed VARCHAR column, you are specifying an
>> upper-bound on the size of the strings it can index (not to mention,
>> store!).  To me, this is analagous to specifying a key-size..
>>
>> If you are willing in your application, to restrict the length of
>> e-mail addresses to the length of whatever you would make the VARCHAR
>> column, then you can choose an appropriate key-size to handle that
>> length and not have to do the post-detect.
>
> I don't want to create a new class for the index, so my options are:
>
> - limit the size of the input string for the #email field and choose a
> keySize for the MagmaIndex that have enough meaningful characters
> - use the post-detect to obtain the wanted value from the collection.
>
>
>>
>> Finally,
>>
>>> I think that this is a point where the requirements for the developers can
>>> be a little too much. See it this way, we are only indexing a string. It
>>> shouldn't be necessary to implement a hash code for converting them to
>>> numbers.
>>
>> As you get deeper into it, I hope you'll find the MaByteSequenceIndex
>> hierarchy included in the base Magma package is flexible enough for
>> use "out of the box" (but if not, it isn't hard to define your own
>> custom index type).
>>
>> But yes, the key point of this whole thread is the post-detect:
>> required to index "CLOB" values (read: Smalltalk Strings), which is
>> what I would do rather than restricting the user..
>>
>
> I agree, I prefer no to limit the user and do a post-detect.
>
>> Regards,
>>  Chris
>
> Regards,
> Miguel Cobá
>