As is stated in the title. However I need column names to be created exactly as they are, for example I have incoming attribute "OGC_ANGLE.uom" and even though I have Lower Case Attribute Names unchecked,
tables in database have column names are created lowercase ("OGC_ANGLE.uom" becomes ogc_angle_uom) - this is a problem, if I read those tables and try to use xsd to create gml again, as these attributes are unknown to the xsd, therefore failing creation of the gml. I could manually rename those columns, however I would need to rename those columns every time xsd file changes, which is why I need to do this dynamically in the first place, as those xsd files are going to be updated quite often...
And it seems that the dynamic PostGIS writer ignores Table Qualifier, it always creates tables in default schema, unless I specify schema in Table Name (schema.@Value(fme_feature_type))
Page 1 / 1
Hi @drejkzet,
Sorry that you are running into this issue. This is a known problem where when you use the PostGIS writer to write dynamically it acts as though the 'Lower Case Attribute Names' box is always checked. I have assigned this Question to the issue so should a fix be put in place you will be notified here.
Hi @drejkzet,
Sorry that you are running into this issue. This is a known problem where when you use the PostGIS writer to write dynamically it acts as though the 'Lower Case Attribute Names' box is always checked. I have assigned this Question to the issue so should a fix be put in place you will be notified here.
Hi @hollyatsafe, we're still running into this issue with FME 2020.0.3 build 20252. Do you have a timeline for when this will be fixed?
Hi @hollyatsafe, we're still running into this issue with FME 2020.0.3 build 20252. Do you have a timeline for when this will be fixed?
Hi @david_r,
Upon review this bug is currently blocked by work that needs to go into a separate but related issue. I have raised this with one of our FME Desktop Product Owner's to try and get the ball rolling and she is going to take a look and determine what is needed for us to be able to implement a fix.
Hopefully I'll have some more information for you on this shortly.
FME 2021.1 and the bug is always here.
Thats a really big bug for me as it is nearly impossible to use dynamic feature type with PostgreSQL or PostGIS. Dynamic features and schema are one of the best feature of FME, really sad to have this bug since so long.
@hollyatsafe have you some news about this trouble ?
Thank you
FME 2021.1 and the bug is always here.
Thats a really big bug for me as it is nearly impossible to use dynamic feature type with PostgreSQL or PostGIS. Dynamic features and schema are one of the best feature of FME, really sad to have this bug since so long.
@hollyatsafe have you some news about this trouble ?
Unfortunately, the bug is still blocked by various issues that are preventing it from being fixed. Issues to do with dynamic mode can be quite complex and in this case, the issue expands beyond the PostgreSQL and PostGIS format, increasing the effort needed to solve the issue. At the moment, we're still hoping to get a fix out sometime in the future, but I can't give a concrete date.
Also, I have made note of your concerns on the bug report so you will be notified when we have an update.
Unfortunately, the bug is still blocked by various issues that are preventing it from being fixed. Issues to do with dynamic mode can be quite complex and in this case, the issue expands beyond the PostgreSQL and PostGIS format, increasing the effort needed to solve the issue. At the moment, we're still hoping to get a fix out sometime in the future, but I can't give a concrete date.
Also, I have made note of your concerns on the bug report so you will be notified when we have an update.
Thanks for your quick answer.
It's a really bad news as I was hoping that this bug could be resolved quickly.
Thank you for the notification.
Have a nice day.
FME 2023.0.0.3 and the bug is always there...
New brand design, higher prices (that climb to summit) but the same mecanics...
Really desapointed that FME is still not fully compatible with PostgreSQL witch is the minimum required for any GIS software in 2023 (maybe since 5 or 10 years now).
I understand that there may be some complex things behind this problem but this is really anoying and a minimum when you work with Oracle and PostgreSQL...
If you can put a little poke on this issue that will be really appreciated on our side.
Thank's !
Best regards !
FME 2023.0.0.3 and the bug is always there...
New brand design, higher prices (that climb to summit) but the same mecanics...
Really desapointed that FME is still not fully compatible with PostgreSQL witch is the minimum required for any GIS software in 2023 (maybe since 5 or 10 years now).
I understand that there may be some complex things behind this problem but this is really anoying and a minimum when you work with Oracle and PostgreSQL...
If you can put a little poke on this issue that will be really appreciated on our side.
Thank's !
Best regards !
Hey @arthur_bazin just wanted to give you an update on the progress with resolving the bug. As mentioned before, the bug was blocked by various other issues that first needed to be resolved to get this functioning correctly. Fortunately, these blocking issues have now been resolved which means the team can move forward with resolving this issue.
I've reached out to our FME Engine product manager to share you concerns as well. This bug has long since been one we've looked forward to resolving and I know we're one step closer to getting there now that it isn't blocked by that other issue. We'll keep you updated throughout the process and let you know when we you can expect to see the fix for the issue released.
Thanks again for your patience and generous feedback!
Hey @arthur_bazin just wanted to give you an update on the progress with resolving the bug. As mentioned before, the bug was blocked by various other issues that first needed to be resolved to get this functioning correctly. Fortunately, these blocking issues have now been resolved which means the team can move forward with resolving this issue.
I've reached out to our FME Engine product manager to share you concerns as well. This bug has long since been one we've looked forward to resolving and I know we're one step closer to getting there now that it isn't blocked by that other issue. We'll keep you updated throughout the process and let you know when we you can expect to see the fix for the issue released.
Thanks again for your patience and generous feedback!
Thank you very much for your answer and for this great news.
Hope to see this issue resolved in a few times :-D
I would like to be updated on this issue since I have the same problem.
Br
Felipe Verdú
Hi @felipeverdu we'll make sure to update you (as well as everyone else) about this issue when it's resolved.
I'm aware of some upcoming changes in FME 2024.0 that will allow users to un-check the Create Generic Spatial Columns parameter and the Lower Case Attribute Names parameter with a normal dynamic PostGIS/PostgreSQL Writer.
The fix mentioned above does not include the FeatureWriter unfortunately as that still being resolved. Since I don't see it here yet, the tracking number for this issue/bug is FMEENGINE-9157.
Hi @danminneyatsaf
Any update on a fix for this issue? I can’t see it have been resolved for dynamic PostGIS/PostgreSQL writer in FME 2024.0. Thanks!
Kind Regard
Mats
Hi @mats_anderberg, unfortunately the issue is still unresolved at the moment. As I mentioned in my other comment, you can use the normal Dynamic PostGIS Writer normally in 2024.0, but the bug will still exist if you use the FeatureWriter. For now this is our recommended workaround as we continue to assess the issue.
Regards,
Dan M
That is great but I have tested un-checking the “Lower Case Attribute Names” checkbox for a dynamic PostGIS writer in FME 2024.0 and it still gets checked again upon saving (the same behavior applies to “Create Generic Spatial Columns”). So for me it is not working but I might be missing something.
@mats_anderberg what build of FME 2024.0 are you using? I’ll try testing with the same version and see what’s going on here.
It is Build 24187. Thanks!
@mats_anderberg can you give the workspace attached to this reply a try? It works ok for me.
It just reads in a small shapefile dataset of bike paths and creates a table called BikePaths_M in PostGIS. The column names should be TitleCase and the Geometry should be LineString.
You’ll also need to replace the connection in the workspace with your own PostGIS connection before running.
Cheers,
Dan M
Hi @danminneyatsaf Thanks for your time on this. I get it to work now, both your attached workspace and mine. I updated the writer, unchecking the checkbox for “Lower Case Attribute Names” and ran the workspace and it works. But if I then go to the writer settings again to check the setting, the checkbox is checked again. And I think that’s what I did earlier. I updated the writer and then went to check that the settings where ok, I never ran it directly. Can you reproduce that behavior, that the checkbox is checked again when you revisit the writer settings? I would expect it not to be.
@mats_anderberg thanks for the additional details. I can see the same issue when updating the PostGIS writer. I created a separate ticket for this to get this resolved as this can be quite confusing to the user if they’re expecting it to show up as un-checked. For your reference, the ticket number for this bug is FMEFORM-31154. We’ll update you here when a fix has been released.
Thanks @danminneyatsaf . Will you release a patch for FMEENGINE-9157 on FME 2023 also?
@danminneyatsaf Can you get back to me on whether you plan to release a patch for this issue on FME 2023 or if it will only be available from FME 2024.0? Thanks!
@mats_anderberg apologies for the delayed reply. The patch for FMEENGINE-9157 that resulted in the regular PostGIS Writer functioning correctly will not be backported to FME 2023 unfortunately.
If you have a business case for a backport I can discuss the issue with our developers and see what’s possible, however I know we typically don’t backport to the previous year’s version (FME 2023 in this case)
Hi all, as of FME 2024.1, the FeatureWriter also respects the Create Generic Spatial Columns and Lower Case Attribute Names parameters. This means you should now be able to use the FeatureWriter to write out PostGIS tables dynamically with these parameters unchecked, and see the expected behaviour.
Regards,
Dan
Hi, I’ve juste seen this resolved issue in my workspace that have just created uppercase attribute instead of lowercase after updating FME.
I didn’t seen anything into the changelog.
The resolution of this issue is a great news BUT not being aware of this change can have a big impact on production scripts.
@danminneyatsaf Can you add it to your changelog ?
