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 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

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