Performance
Compression
Actually ds_transfer object is what compresses databases. The old compression object is no longer supported in 5.x and lacked true options.
Here is code that will compress all files in a view…
UVAS
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.
UVA Usage
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.
UVA Allocation
These are general notes. may not be 100% correct. Seek Smallworld support for your specific needs
UVAs are "allocated" to each alternative based off the max divided by nslots. Max & Nslots are determined from details method on the uva (ie, view.uvas[:sw_gis!spatial_id].details). So if the max is 10000 and the nslots are 1000, 10 UVAs are allocated to the alternative when the 1st ds_uva.get() is called. This allows you a max of 1000 alternatives (with single used bucket) to be generated prior to an exhaustion message. As "buckets" are allocated the number of available alternatives decreases. seek support for your specific needs
When replicas are created, the max is redefined on the master database and is recorded in the replication_metadata.ds. You must keep the replication_metadata.ds with your other DS files in perpetuity! Don't delete the META file! Even if all replicas are returned and deleted the meta file is required. When you create a replica the 1st time, the master database is allocated ~20% of the total UVA pool. At which point you will always need to consider UVA usage/allocation in the future. So determine if you really want a replica before creating one. Consider ds_transfers/backups for non returnable copies.
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.
Mapped Geometry
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
record.self_destruct()
This method removes the record from the table. No triggers are run and join tables (including geometries) are not updated.
collection.clone_record(a_rec)
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.
Copying Data
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:
targetCollection.int!insert_or_update(sourceRec.int!values_as_vector())
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…
Database Files
Opening Copied DS Files
There are times when you need to open a copied set of DS files at the same time as the original. However the system will prevent this and give a message about duplicate database headers. Here are a couple of ways to open them
Open with New World
dup_view.add_file("gis2.ds", :world,ds_world.new(1000))[1]
Renumbering Dataset File Header
If you copy a set of DS files and try to open them up with the original files, you will get an error about the dataset file being open already. Here is some code that will renumber the DS Header info.
SOC Administration
Modifying SOC Definitions at Magik Prompt
Be careful here
GIS Program Manager Methods
- !params « gis_program_manager.file_parameters(:gis,"")
- gis_program_manager.set_file_parameters(:gis,"",!params)
Dataset Manager Object
- !dsm « gis_program_manager.spatial_object_controller.dataset_managers[:gis]
- !conn_spec « !dsm.get_connect_spec()
- !dsm.store_connect_spec(!conn_spec)
