1. Forum
  2. Usenet
  3. COMP.LANG.SMALLTALK.DOLPH

  • Clean way to handle multi-keyed tables in ReStore

    From Scott McWilliams@21:1/5 to All on Thu Nov 4 13:23:35 2021
    Does anyone have any suggestions on how to handle multi-keyed records cleanly in ReStore? I've used a unique integer as a surrogate key in the past, and I know you can use defineAsID: for single keys including strings, but I need to do something where
    a record has a string name _and_ a numeric version (separate from the _version provided by ReStore) so the version can be incremented by the user when they choose to do so, so it appears something like this in the DB:

    NAME VERSION ...
    TEST_1 1

    The _version field could be any value depending on how many changes have been made to the object, but the VERSION field could remain at 1 until explicity versioned by the user.

    Any ideas greatly appreciated.

    Thanks,
    Scott

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From john.aspinall@gmail.com@21:1/5 to Scott McWilliams on Fri Nov 5 02:15:30 2021
    Hi Scott,

    Are you saying the string name and numeric version form a composite key? i.e. there could be more than one record with the same name, but they'd all have different versions? ReStore doesn't currently support composite keys (keys consisting of multiple
    instance variables/fields) so you'd need to find another way to handle this unfortunately.

    Note there's been a recent enhancement to ReStore to allow more flexibility in primary key types, mainly to accommodate GUID/UUID keys but also others e.g. Strings (I don't *think* ReStore previously supported String keys, at least if it did it was
    accidental). These haven't been added to the documentation yet but the relevant test classes should provide some clues - see SSWReStoreAlternativeIDTest and subclasses. Also see implementors of the following methods:

    reStoreIDClass
    reStoreNewUniqueID
    reStoreNewUnique

    Hope this helps.

    John


    On Thursday, November 4, 2021 at 8:23:36 PM UTC, Scott McWilliams wrote:
    Does anyone have any suggestions on how to handle multi-keyed records cleanly in ReStore? I've used a unique integer as a surrogate key in the past, and I know you can use defineAsID: for single keys including strings, but I need to do something where
    a record has a string name _and_ a numeric version (separate from the _version provided by ReStore) so the version can be incremented by the user when they choose to do so, so it appears something like this in the DB:

    NAME VERSION ...
    TEST_1 1

    The _version field could be any value depending on how many changes have been made to the object, but the VERSION field could remain at 1 until explicity versioned by the user.

    Any ideas greatly appreciated.

    Thanks,
    Scott

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott McWilliams@21:1/5 to john.a...@gmail.com on Fri Nov 5 05:25:56 2021
    On Friday, November 5, 2021 at 4:15:31 AM UTC-5, john.a...@gmail.com wrote:
    Hi Scott,

    Are you saying the string name and numeric version form a composite key? i.e. there could be more than one record with the same name, but they'd all have different versions? ReStore doesn't currently support composite keys (keys consisting of multiple
    instance variables/fields) so you'd need to find another way to handle this unfortunately.

    Note there's been a recent enhancement to ReStore to allow more flexibility in primary key types, mainly to accommodate GUID/UUID keys but also others e.g. Strings (I don't *think* ReStore previously supported String keys, at least if it did it was
    accidental). These haven't been added to the documentation yet but the relevant test classes should provide some clues - see SSWReStoreAlternativeIDTest and subclasses. Also see implementors of the following methods:

    reStoreIDClass
    reStoreNewUniqueID
    reStoreNewUnique

    Hope this helps.

    John
    On Thursday, November 4, 2021 at 8:23:36 PM UTC, Scott McWilliams wrote:
    Does anyone have any suggestions on how to handle multi-keyed records cleanly in ReStore? I've used a unique integer as a surrogate key in the past, and I know you can use defineAsID: for single keys including strings, but I need to do something
    where a record has a string name _and_ a numeric version (separate from the _version provided by ReStore) so the version can be incremented by the user when they choose to do so, so it appears something like this in the DB:

    NAME VERSION ...
    TEST_1 1

    The _version field could be any value depending on how many changes have been made to the object, but the VERSION field could remain at 1 until explicity versioned by the user.

    Any ideas greatly appreciated.

    Thanks,
    Scott
    Hi John,

    Thanks for your reply. Yes, the scenario involves a composite key. I have it working using a 'versions' table but it's rather klugey at the moment, so I was hoping for something a bit more elegant.

    No worries. I have the latest version of ReStore and have been looking at the methods you mentioned in order to revise my code to use strings as primary keys (where applicable) along with the versioning I already have. That new capability will make
    things a bit cleaner for me and better suit the situation for users as well.

    Thanks again for all your great work!

    Regards,
    Scott

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)