postgis schema

Hi Mats,

 

 

I talked with the Database Team and we think this should be working but at first blush appears not to be.  I've created a case for it and support will verify that it doesn't work, see if there's a workaround for the short term, and then we'll try to get it fixed for a 2015.1.x.

 

 

Sorry about this one.

 

 

Dale

Hi Mats,

 

 

We looked into this further. FME's PostGIS writer honors "Table Qualifier" with feature type fanout (where the output table name comes from an attribute), but not dynamic writing (which is even more flexible than feature type fanout and additonally copies schemas from readers).

 

 

We understand the causes behind this limitation and do plan to address it in future - but possibly not soon enough for your use case. Could you let us know if the following workaround is sufficient?

 

 

1. Find the attribute that contains the table name FME would write. In the default dynamic case, this is fme_feature_type. If the name is different, adjust the following steps to match.

 

 

2. Use an AttributeCreator to create a new attribute containing the string "<table qualifier>.<fme_feature_type>".

 

 

3. In the destination feature type General tab, set "Table Name" to this new attribute.

 

 

4. In the destination feature type General tab, Dynamic Properties section, set "Schema Definiton Name" to Attribubutre Value -> fme_feature_type. You may need to check "fme_feature_type" in the source feature type properties, Format Attributes tab, to make this option available.

 

 

Regards,

 

 

Paul

 

 

––––––––––––––––––––––––––––––––

 

 

Paul Nalos | Database Team Lead

 

 

Safe Software Inc.

 

T 604.501.9985 x 301

 

paul.nalos@safe.com | www.safe.com

 

 

––––––––––––––––––––––––––––––––

Hi Mats,

 

 

We looked into this further. FME's PostGIS writer honors "Table Qualifier" with feature type fanout (where the output table name comes from an attribute), but not dynamic writing (which is even more flexible than feature type fanout and additonally copies schemas from readers).

 

 

We understand the causes behind this limitation and do plan to address it in future - but possibly not soon enough for your use case. Could you let us know if the following workaround is sufficient?

 

 

1. Find the attribute that contains the table name FME would write. In the default dynamic case, this is fme_feature_type. If the name is different, adjust the following steps to match.

 

 

2. Use an AttributeCreator to create a new attribute containing the string "<table qualifier>.<fme_feature_type>".

 

 

3. In the destination feature type General tab, set "Table Name" to this new attribute.

 

 

4. In the destination feature type General tab, Dynamic Properties section, set "Schema Definiton Name" to Attribubutre Value -> fme_feature_type. You may need to check "fme_feature_type" in the source feature type properties, Format Attributes tab, to make this option available.

 

 

Regards,

 

 

Paul

 

 

––––––––––––––––––––––––––––––––

 

 

Paul Nalos | Database Team Lead

 

 

Hi Paul!

 

That is absolutely brilliant. It worked at the first attempt, and further development such as putting a uuid creator on the path worked as well. I just put some 6.3 million objects into PostGIS, GIST:ed and vaccuumed in 46 minutes.

 

I did try to inject the table qualifier as an attribute, but failed to make it dynamic. But your suggestion also showed me how to alter table names in a workflow, something I have not managed to figure out by myself before but often needed.

 

The workaround is simple enough, but it would surely be fine if the table qualifier did work in dynamic mode as well. I see no reason why not, and it is necessary I think for structured PostGIS storage.

 

 

Best regards, Mats.E

fmelizard wrote:

Hi Mats,

 

 

We looked into this further. FME's PostGIS writer honors "Table Qualifier" with feature type fanout (where the output table name comes from an attribute), but not dynamic writing (which is even more flexible than feature type fanout and additonally copies schemas from readers).

 

 

We understand the causes behind this limitation and do plan to address it in future - but possibly not soon enough for your use case. Could you let us know if the following workaround is sufficient?

 

 

1. Find the attribute that contains the table name FME would write. In the default dynamic case, this is fme_feature_type. If the name is different, adjust the following steps to match.

 

 

2. Use an AttributeCreator to create a new attribute containing the string "<table qualifier>.<fme_feature_type>".

 

 

3. In the destination feature type General tab, set "Table Name" to this new attribute.

 

 

4. In the destination feature type General tab, Dynamic Properties section, set "Schema Definiton Name" to Attribubutre Value -> fme_feature_type. You may need to check "fme_feature_type" in the source feature type properties, Format Attributes tab, to make this option available.

 

 

Regards,

 

 

Paul

 

 

––––––––––––––––––––––––––––––––

 

 

Paul Nalos | Database Team Lead

 

 

Was a fix ever implemented into 2016? I currently have the same issue described by @matself. The work around described by@paulatsafe does work, but would be nice to have this functionality working properly for a tidy workbench!

thomaswicks202 wrote:

Was a fix ever implemented into 2016? I currently have the same issue described by @matself. The work around described by@paulatsafe does work, but would be nice to have this functionality working properly for a tidy workbench!

Hi @thomaswicks202 - I don't believe this has been fixed yet. It looks like PR#62362 and that is still an open issue. I will add a link to this thread and see if I can increase the priority. Apologies for the problems it is causing you. If you would like, please do contact our support team directly (safe.com/support) so you can get direct updates on this issue.