Known Issues, Limitations, and Changes to Default Behavior
Following are known issues, limitations, and changes to default behavior in the OmniSci Platform.
OmniSciDB
Do not set BLOSC_*
environment variables
OmniSci uses a compression library called BLOSC that reads operating system environment variables and changes behavior according to those variables. Do not set any of the environment variables listed below.
BLOSC_CLEVE BLOSC_SHUFFLE BLOSC_TYPESIZE BLOSC_COMPRESSOR BLOSC_NTHREADS BLOSC_BLOCKSIZE BLOSC_NOLOCK BLOSC_SPLITMODE
OPTIMIZE TABLE with VACUUM
increases metadata
The with (vacuum = 'true')
option has the suboptimal
effect of increasing the size of your metadata in OmniSci Core version
4.5.0. Do not use the vacuum option.
ALTER TABLE ADD COLUMN
does not work with geo column type
ALTER TABLE ADD COLUMN
for a geo column type in
MapD 4.1 only partially adds the column.
Any queries on that column will result in a system failure.
If you encounter this issue, contact OmniSci support at
support@omnisci.com.
This issue was fixed in MapD version 4.1.1.
MapD 4.0 backward compatibility with MapD 3.x
MapD 4.0 includes several major changes that can affect compatibility with 3.x releases.
Important | MapD recommends you make a backup of your 3.x installations before proceeding with the upgrade to MapD 4.0 so that you can revert if the upgrade is unsuccessful or problematic. |
For assistance during the upgrade process, contact OmniSci support at support@omnisci.com before you upgrade your system.
Migration from releases 3.2.1, 3.2.2, or 3.2.3
There is a known issue with automatic migration if the source database was migrated through any of the following releases: 3.2.1, 3.2.2 or 3.2.3. Contact OmniSci support before you update to v4.0.0 if you think this is the case with your database.
Object permissions and role-based access control on by default in MapD 4.0
If you are using MapD 3.x, setting up MapD 4.0 over an existing 3.x installation data directory migrates existing users and databases to use the new model automatically.
If you encounter issues during upgrade, you must restore your 3.x installation data from backup. Back up your 3.x installations before upgrading to MapD 4.0. You cannot downgrade MapD 4.0 data directories to use them in MapD 3.x installations.
Possible integer overflow on select count(*) for tables with more than 2^32 rows
To prevent return of negative counts, set bigint-count = true
in omnisci.conf
.
Disable Error-correcting Memory before GPU installation
If you are using a server with an NVIDIA Tesla K80 card, you must turn off Error-correcting Code Memory (ecc) before you install OmniSci.
To disable Error-correcting Code Memory
- Open a terminal window on your host machine.
- Run the following command:
sudo nvidia-smi --ecc-config=0
- Reboot your host machine
For more information, see:
NVIDIA-SMI documentation
https://www.nvidia.com/en-us/data-center/tesla-k80/
https://developer.nvidia.com/cuda-downloads
DELETE works only on tables created using MapD 4.0 or later
DELETE
functionality does not work on tables created using MapD 3.x. For DELETE
to function correctly, create a new table in MapD 4.0 with the same schema, and then copy the data.
NOTE: To remove all rows from a table, use TRUNCATE TABLE
instead of DELETE * FROM <table>
.
UPDATE limitations
- OmniSci does not currently support
UPDATE
from a subquery. For example, the following will not work:UPDATE tempDataView SET marks = ( SELECT marks FROM tempData b WHERE tempDataView.Name = b.Name )
UPDATE
is not currently supported on variable-length data types.
OmniSci Rendering Engine
Sizing points by meters at large zoom levels introduces error
When evaluating the new convert_meters_to_pixel_width
and convert_meters_to_pixel_height
extension functions for accuracy against circular polygons
created with ST_Buffer in other packages, some errors are
introduced by the extension functions somewhere at large zoom
levels.
The resulting point/symbol sized by meters is just an approximate. It does not represent the exact area on the globe. There is more error in the approximate as you get closer to the poles in a mercator-projected view: a circle defined in meters should become egg-shaped, whereas the current symbol remains elliptical.
Workaround: If your clients are going to use these extension functions,
OmniSci recommends you use the legacysymbol
vega
mark type if the size in meters is large and zooming in close is
useful for your analysis.
MapD 3.x shapefiles must be reimported for MapD 4.0
If you imported shapefiles into MapD 3.x, you must reimport this data in MapD 4.0 to use the new storage model for geospatial data types. Identify the tables you need to reimport and do so before using MapD 4.0.
Migrate custom client polygon rendering and hit-testing for MapD 4.0
If you imported polygon data into MapD 3.x for a custom application and are rendering or performing hit-testing on that data, upgrading to OmniSci 4.0+ will break your client-side polygon code because the storage model is different. For guidelines on migrating your code for OmniSci 4.0, see Migrating Polygon Rendering and Hit-testing for Custom Clients Upgrading to OmniSci 4.0+.
OmniSci Immerse
High-precision timestamp limitation
You can import higher-precision timestamps (3, 6, 9, milli, micro, nano, rather than the default of seconds) via the data manager, but you cannot use them as a part of the actual queries or filters for a chart (as opposed to displaying them as results). For example, you cannot use a high-precision timestamp as the time dimension for a combo chart.
Dashboard sharing limitations
- In MapD 4.0, dashboards can be shared only as 'read-only'. Users with whom a dashboard has been shared cannot currently make edits to the dashboard.
- For security reasons, dashboard sharing does not automatically provide permissions on underlying tables/views. For now, this requires a one-time setup by a superuser/administrative to configure a group of users or a role with permissions on the underlying objects.
- Dashboard sharing does not currently work in OmniSci Cloud because each OmniSci Cloud user currently has a dedicated OmniSci instance. This limitation will be addressed in a future release.
Dashboards loaded by ID instead of name
If your OmniSci instance is set up to autoload specific dashboards on login by specifying the name in servers.json, you need to update the entry to use the dashboard ID instead. If you do not, your dashboards will not autoload. Find the dashboard ID by running `\dash` from omnisql, and then update the servers.json entry accordingly:
[ { "database": "omnisci", "master": "true", "username": "user", "password": "HyperInteractive", "url": "http://webserver.com:9092", "loadDashboard": "740", "GTM": "GTM-MDD8888" } ]
Immerse backward compatibility
MapD Immerse versions 3.4.0 and higher work only with MapD Core versions 3.4.0 and higher.
Unexpected update queries for Line and Histogram charts
Any update on Line or Histogram charts also starts an update query for range chart that is not required.
Unexpected render of complex data fields exported to CSV format
Binned columns and date extracts appear as JSON strings when exported to CSV format.
Adding layers in the Pointmap chart does not work when using Firefox browser
Sorting by non-grouped column in a table chart might not work properly in a distributed configuration
Old share links no longer load and render immediately.
Old share links (for example, https://www.mapd.com/demos/ships/#/link/mapd/228ae04e) no longer load and render all charts immediately. You must resize the browser or otherwise cause the page to re-render to see all charts.