When I add a column with type POINT in the EER Diagram, is there anything I can do with that diagram so when I generate automatically the scripts, SRID 4326 is attached to CREATE TABLE script? If I don't setup that number, then by default is zero (flat), but I do need 4326 (sphere).
If not possible, does that mean I cannot synchronise my model with my server automatically and I have to add these changes manually all the time?
I couldn't figure this out either. I believe adding a SRID to a column is currently not supported by MySQL Workbench.
To check that it is indeed not supported, I did the following:
Added a SRID to a column of an existing DB
Reversed engineered a script of this DB (using Workbench)
Checked the script if it included the set SRID for the column
Was disappointed that it didn't...
The "good" news is though, that as it is not supported, MySQL Workbench won't pick up on a missing SRID on a column when synchronizing sources.
This means that once you set the SRID on a column yourself, it won't cause any problems when synchronizing in the futures.
Note that in order to set a SRID on a column, there can't be a (spatial) index on that column. Therefore, you must remove the index, set the SRID and then add the index back.
Below is a short and simple script, which I used to do this. Don't forget to update it to your use-case:
DROP INDEX `my_idx` ON my_table;
ALTER TABLE my_table MODIFY COLUMN my_column POINT NOT NULL SRID 4326;
ALTER TABLE my_table ADD SPATIAL INDEX `my_idx` (`my_column`) VISIBLE;
Related
I merged lines in a shapefile layer and need to copy them to a postgreSQL database layer. If I paste them to the pg db layer, it does not work. If I merge them, after I pasted to QGIS, it crashes. I figured out that it works, if I export the pg db layer to a geopackage or shapefile layer and set the geometry from linestring to multilinestring. The problem is that I need it to bring to the data base layer. Anyone can give me a hint how I configure the db layer in the right way?
Thank you!
I would change the geometry type in PostgreSQL not in the geopackage or shapefile. The problem seems to be in the geometry type column. You could use this to change it:
ALTER TABLE [table_name]
ALTER COLUMN [geometry_column] TYPE geometry(MULTILINESTRING) USING ST_Multi([geometry_column]);
OR
You could import in PostgreSQL the lines without merging them and to that in with postgis while altering the geometry type of the column:
ALTER TABLE [table_name]
ALTER COLUMN [geometry_column] TYPE geometry(MULTILINESTRING) USING ST_Union([geometry_column]);
Also, this might help you:
https://gis.stackexchange.com/questions/68071/how-to-create-a-multilinestring-feature-with-a-postgis-layer-in-qgis
It's been a while.
Using DB2 10 for z/OS, I've been asked to change a specific column in a table from decimal(7,2) to decimal(7,4). Sounds easy, right?
alter table MySchema.MyTable
alter column myColumn
set data type decimal(7,4);
But, DB2 responds with this error: "Attributes specified for column 'MYCOLUMN' are incompatible with existing column definition."
I had thought that converting from decimal(7,2) to decimal(7,4) would be pretty straightforward, but DB2 disagrees.
Outside of dropping the table and recreating it from scratch, what alternatives do I have?
Thanks in advance!
Dave
The reason Db2 doesn't like that change is you're going from from 99999.99 to 999.9999
Is that really what you want? Going from (7,2) to (9,4) would just add two more decimal places without losing any data and should be allowed by the Db.
Db2 for i gives a warning, but allows you to ignore the warning...
Create a new column ALTER ADD COLUMN of the right type, use an UPDATE to populate it, ALTER DROP COLUMN the old column. RENAME COLUMN so set the name of the original column.
I'm using a database created in the PostgreSQL. In its schema there are two tables and in one of them I want to add a geometry column.
The problem is that I created the postgis Extension (CREATE EXTENSION postgis;) for the database, but I'm not able to add this data type (geometry) column using pgAdmin.
To do this with pgAdmin's "New Column..." dialog, if you can't find geometry, then you might be able to find public.geometry instead (if PostGIS was installed there, which is normal).
However, I advise against using pgAdmin for creating geometry columns, as it does not understand typmods used to define the geometry type and SRID.
The best way is using DDL to directly manipulate the table, e.g.:
ALTER TABLE locations ADD COLUMN geom geometry(PointZ,4326);
to add a geom column of XYZ points (long, lat, alt).
I have a table in postgresql with a PostGIS geometry(point, 4326) column (location, using SRID 4326) and I have a Python application that using SQL Alchemy updates the table (the rest of the columns) without any problem.
Now, I need to update the location column and I know I can use the proper text representation of a given location to update the column using SQL Alchemy without the need to use GEOAlchemy, for instance I can update the column with the value: '0101000020E6100000AEAC7EB61F835DC0241CC418A2F74040'
which corresponds to lat:33.9346343 long:-118.0488106
The question is: is there a way to compute in Python this '0101000020E6100000AEAC7EB61F835DC0241CC418A2F74040' having this (33.9346343 ,-118.0488106) as an input without querying the database? or any way to update the column using a proper text input?
I know I can use SQLAlchemy to execute this query:
select st_setsrid(st_makepoint(-118.0488106, 33.9346343),4326)
and obtain the value to update the column, but I want to avoid that.
Thanks in advance!
The solution to this problem is rather easier than it seems. To update the field using text and the input lat-long all I needed to do was defining the SRID in the text assign:
location = 'SRID=4326;POINT(-118.0488106 33.9346343)'
This will update the geometry(point,4326) column properly and when you do a select in the table the value of the column is the expected one:
"0101000020E6100000AEAC7EB61F835DC0241CC418A2F74040"
Thanks guys!
I have a need to change the length of CHAR columns in tables in a PostgreSQL v7.4 database. This version did not support the ability to directly change the column type or size using the ALTER TABLE statement. So, directly altering a column from a CHAR(10) to CHAR(20) for instance isn't possible (yeah, I know, "use varchars", but that's not an option in my current circumstance). Anyone have any advice/tricks on how to best accomplish this? My initial thoughts:
-- Save the table's data in a new "save" table.
CREATE TABLE save_data AS SELECT * FROM table_to_change;
-- Drop the columns from the first column to be changed on down.
ALTER TABLE table_to_change DROP column_name1; -- for each column starting with the first one that needs to be modified
ALTER TABLE table_to_change DROP column_name2;
...
-- Add the columns back, using the new size for the CHAR column
ALTER TABLE table_to_change ADD column_name1 CHAR(new_size); -- for each column dropped above
ALTER TABLE table_to_change ADD column_name2...
-- Copy the data bace from the "save" table
UPDATE table_to_change
SET column_name1=save_data.column_name1, -- for each column dropped/readded above
column_name2=save_date.column_name2,
...
FROM save_data
WHERE table_to_change.primary_key=save_data.primay_key;
Yuck! Hopefully there's a better way? Any suggestions appreciated. Thanks!
Not PostgreSQL, but in Oracle I have changed a column's type by:
Add a new column with a temporary name (ie: TMP_COL) and the new data type (ie: CHAR(20))
run an update query: UPDATE TBL SET TMP_COL = OLD_COL;
Drop OLD_COL
Rename TMP_COL to OLD_COL
I would dump the table contents to a flat file with COPY, drop the table, recreate it with the correct column setup, and then reload (with COPY again).
http://www.postgresql.org/docs/7.4/static/sql-copy.html
Is it acceptable to have downtime while performing this operation? Obviously what I've just described requires making the table unusable for a period of time, how long depends on the data size and hardware you're working with.
Edit: But COPY is quite a bit faster than INSERTs and UPDATEs. According to the docs you can make it even faster by using BINARY mode. BINARY makes it less compatible with other PGSQL installs but you won't care about that because you only want to load the data to the same instance that you dumped it from.
The best approach to your problem is to upgrade pg to something less archaic :)
Seriously. 7.4 is going to be removed from "supported versions" pretty soon, so I wouldn't wait for it to happen with 7.4 in production.