Magma April 2006

magma@lists.squeakfoundation.org

4 participants
6 discussions

[Q] changing keySize:
by Norberto Manzanos 25 Apr '06

25 Apr '06

Sorry for bother you with these elementary questions. I am playing with differentes keySizes in indexes, but everytime I change the keySize of an index and rebuild the database Squeak hungs (or it takes too much time to do the task). I'm saveving only 200 objects in a one single entry with two indexes. The first time I save them, its very fast, but when I begin playing with differents keySizes, Squeak loops. Normally I close the session (a single user sesssion) and reopen it, before to rebuild the database and the indexes, but I have tried even deleting the db files and recreate them. I thought its must be something about references that remains in my image, so I try to find how to perform a garbageCollect of Magma. I found a comment in MagmaCompressor that says "yourRepositoryController garbageColllect". But this object does not understand #garbageCollect, nor any other magma object. Would you give me any hint? Or something to read about that? Thank you in advance. Norberto

3 8

Magma tester-cmm.215
by Chris Muller 14 Apr '06

14 Apr '06

I fixed a typo in the recovery code today. In a disaster-recovery situation, not all MagmaCollectionIndexes would be recovered (only the first three). This is now fixed. - Chris

1 0

Fwd: Re: Reading multiple indices on MagmaCollections - second working code
by Brent Pinkney 10 Apr '06

10 Apr '06

Again and Again with Monticellos... ---------- Forwarded Message ---------- Subject: Re: Reading multiple indices on MagmaCollections - second working code Date: Sunday 09 April 2006 23:21 From: Brent Pinkney <brent.pinkney(a)aircom.co.za> To: Magma list <magma(a)lists.squeakfoundation.org> Hi Chris, This mail follows on from "Re: Reading multiple indices on MagmaCollections - first working code". I have decided to broaden the scope of this work by adding support for sorting the results. r := LavaTestResource current people where: [ :each | (each familyName equals: 'Man') | ((each familyName equals: 'Pinkney') & (each age to: 60)) ] orderBy: [ :each | each age ascend , each familyName descend ] I have no idea how to implement this yet! The current code does not even pass the 'order' clauses to the server yet. I really think we should try to crack this problem as well - Magma's indices provide really powerful ordering facilities. Cheers Brent ------------------------------------------------------- -------------------------------------------------------

1 1

Fwd: Re: Reading multiple indices on MagmaCollections - second working code
by Brent Pinkney 09 Apr '06

09 Apr '06

Again with Monticellos... ---------- Forwarded Message ---------- Subject: Re: Reading multiple indices on MagmaCollections - second working code Date: Sunday 09 April 2006 23:21 From: Brent Pinkney <brent.pinkney(a)aircom.co.za> To: Magma list <magma(a)lists.squeakfoundation.org> Hi Chris, This mail follows on from "Re: Reading multiple indices on MagmaCollections - first working code". I have decided to broaden the scope of this work by adding support for sorting the results. r := LavaTestResource current people where: [ :each | (each familyName equals: 'Man') | ((each familyName equals: 'Pinkney') & (each age to: 60)) ] orderBy: [ :each | each age ascend , each familyName descend ] I have no idea how to implement this yet! The current code does not even pass the 'order' clauses to the server yet. I really think we should try to crack this problem as well - Magma's indices provide really powerful ordering facilities. Cheers Brent -------------------------------------------------------

1 0

Reading multiple indices on MagmaCollections
by Brent Pinkney 09 Apr '06

09 Apr '06

Hi Chris, I apologise for my silence on this list: work. I would really like to implement the ability to read a MagmaCollection on more than one index. We spoke about this last year but it is now quite pressing. Related to this is the ability to read the same index more than once at different hash values. This is analogous to an SQL select ... where foo in('abc' 'def') I was wondering if you are still interested in this feature and whether we can collaborate on a plan. We need to revive: 1. the client images programming interface 2. the bitmat indices of equivalent Regards Brent

3 10

conjuncting MaHashIndexes
by Chris Muller 06 Apr '06

06 Apr '06

Idea for finding intersections between MaHashIndexes based on multiply anded conditions: If, for every key->oid pair we insert into any MaHashIndex, we also insert into a separate, additional MaHashIndex, oid->key. I will refer to this reverse-mapped index as the "census" index because it answers where is each object. So, with these census indexes we can quickly know, for any oid, all keys it resides at. We have a tree of conjuncted conditions being requested from the user. To (and) conjunct the ranges specified in the tree of a number of MaHashIndexes we could follow these steps: 1) First use #numberOfEntriesFrom:to: to discover which index will have the most-restricted range to enumerate based on the anded conditions of the tree. Call the size of this range "sr". 2) enumerate all the oids from lowKey to highKey of that index. 3) enumerate each of the other census indexes specified by the conditions. 4) determine whether this eachOid should be included in the result. If any censusIndex indicates no, the oid is rejected (because we're anding), move to the next oid. If all censusIndexes have that oid in the key-range, the oid is included. The implementation should be sure to enumerate the Census indexes a max of once. For eachCensusEntry: get the condition for this index# if the key is between: condition lowKey and: condition highKey mark condition satisfied return true if all conditions satisfied return false For example, for a particular oid with these census values and this tree of conditions being anded together Census ANDed Conditions index1 { 100. 319 } index1 -> keys 300 to: 500. index2 { 700 } index2 -> keys 700 to: 900. this oid would be accepted because all conditions were satisfied. Note it existed in two places in index1 (which would happen in a keyword index) but only one of them needs to be satisfied. So, in the worst case, the most number of steps we have to process is sr*number of conditions This does not seem too bad! - Chris

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma April 2006