UVAs (Unique value allocators) are the way Smallworld creates unique ids. In release 4.1 can have either a 32 bit or 64 bit UVA. Of course with 64 bit you basically get an endless number of ids, but at a slight performance cost. If you want to stay at 32 bit and want to expand the number of features you can have you can create your own UVA to be used.
Here is something to note… UVAs for geometry is shared between the geometry and topology and ds_records. If you wanted to separate the uvas for your geometry and topology you need to change int!world.generate_unique_spatial_id() to understand which UVA to use. You would then have to change all the calls to this method so you can know which UVA to grab.
A suggestion would be to create UVAs for top level geometries and for ds_geometry (topology). Then subclass the make_sysid() and change int!world.generate_unique_spatial_id() to use make_sysid() on a geometry or topology link or node.
64 Bit UVA
In later Smallworld versions (4.2 and 4.3 and forward) you have the option of using 64 bit UVAs. Basically this will ensure you never run out of UVAs… Which is great, but boy are the IDs large!
64bit UVAs and TINs
The TINs are not well supported with 64 bit UVAs. As of Aug 2014, there was a proposed patch from GE with new a new TIN ACP, but I couldn't get it to work, and was not given another patch from GE to try. I did modify the calling code to work with 64 bit TINs and it is attached to this page tin_64_bit.zip.
There is decent details in the online help about how to create mapped geometries. Located in Case Tool and Data Model -> Case Tool Tutorial -> 19 Geometry field mapping.
The basic concept is to create your main geometry and then create a geometry for each mapped geometry you want. Example, centerline is the main geometry and then your mapped geometries will be main_road_centerline, minor_road_centerline, trail_centerline. On the centerline geometry select the properties->Mapping.. and add the method and select the mapped geometries (all but main).
However once applied, your existing geometry will not be updated… So you can either recreate the geometry which wastes time and UVAs, you can loop over the records and select the geometry and set it's app_code to the appropriate value.
Advanced Record Manipulation
This method removes the record from the table. No triggers are run and join tables (including geometries) are not updated.
This method inserts a_rec into the table if it doesn't exist or updates the values in the table if it already existed. It preserves the ID. This does not run any triggers or join (including geometries) updates.
Under very unique circumstances should you run self_destruct() and clone_record(). One of these circumstances could be copying data from one alternative to another (like a far merge) but you could select what data you want to copy. Also this is helpful to get around issues where you can't merge an alternative either because it is out of sync with data model versions, or you don't want "all" the changes in an alternative… Note, I have only tested this approach when the data model version added a new field to the table. I don't know if this would work if there was a removal of the field…
Using self_destruct() and clone_record() is very powerful, but you must understand that you would have to do all the bookkeeping to ensure that joins, geometry, and topology are updated correctly. It is very easy to copy data and the results are not useful…
Another Alternative for Copying Data
You can also use the method:
This will insert or update a record in the target collection based on the source record vector. This is similar to clone_record() where this is a straight insert or update to the database. No bookkeeping is done so any referenced geometry will need to be copied separately.
This works for when the record you are cloning has undergone a data model change. You would need to adjust the vector data if you added or removed fields…