ArcSDE Guid types always get overwritten
|
|
Some javascript/style in this post has been disabled (why?)
Hello, I’m looking at the ArcSDE provider, and it seems to me
that the UUID support checked in 12/8/2008 makes it so that ALL GUID fields in
ArcSDE get auto-generated on an insert, not just the ESRI GlobalID fields. Can
anyone verify this for me? We’re losing our primary keys (and foreign
keys) on inserts, and tracing through the codes, that is what it seems to do (ArcSDEInsertCommand.cpp
~ line 210).
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||
|
Some javascript/style in this post has been disabled (why?)
Hi Chris, That could be. Is there a flag
that distinguishes an ESRI GUID field from other GUID fields? Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Chris
Erickson Hello, I’m looking at the ArcSDE provider, and it seems to me that
the UUID support checked in 12/8/2008 makes it so that ALL GUID fields in
ArcSDE get auto-generated on an insert, not just the ESRI GlobalID fields.
Can anyone verify this for me? We’re losing our primary keys (and foreign
keys) on inserts, and tracing through the codes, that is what it seems to do
(ArcSDEInsertCommand.cpp ~ line 210).
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||
|
|
Some javascript/style in this post has been disabled (why?)
Orest, Unfortunately there isn’t that I
can see. I’m about to start working on a
fix here for our build, which I’ll submit to FDO. In my testing here, I’ve found
several things: 1)
GlobalIDs are GUIDS
where required = true. 2)
If I add a text
field to a table called GlobalID, then use ArcCatalog to ‘Add Global IDs’, then
it adds a new field called GlobalID_1. So, I think we could correctly establish
‘GlobalIDness’, with several conditions: 1)
It is a UUID column* 2)
It is set to ‘Nullable
= false’ 3)
It’s name starts
with ‘GlobalID’ (* is the only condition currently
used to determine if it is a global ID) Any thoughts on this in general?
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak Hi Chris, That could be. Is there a flag
that distinguishes an ESRI GUID field from other GUID fields? Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Chris Erickson Hello, I’m looking at the ArcSDE provider, and it seems to me that
the UUID support checked in 12/8/2008 makes it so that ALL GUID fields in
ArcSDE get auto-generated on an insert, not just the ESRI GlobalID
fields. Can anyone verify this for me? We’re losing our primary
keys (and foreign keys) on inserts, and tracing through the codes, that is what
it seems to do (ArcSDEInsertCommand.cpp ~ line 210).
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||
|
|
Some javascript/style in this post has been disabled (why?)
All, I’d like to submit the attached
patch for GUID types always getting over-written with the ArcSDE provider. It uses the proposed logic to
determine whether it is a GlobalID or just a normal GUID field. This is a patch for the 3.4.0
branch.
From:
[hidden email] [mailto:[hidden email]]
On Behalf Of Chris Erickson Orest, Unfortunately there isn’t that I
can see. I’m about to start working on a
fix here for our build, which I’ll submit to FDO. In my testing here, I’ve found
several things: 1)
GlobalIDs are GUIDS
where required = true. 2)
If I add a text field
to a table called GlobalID, then use ArcCatalog to ‘Add Global IDs’, then it
adds a new field called GlobalID_1. So, I think we could correctly
establish ‘GlobalIDness’, with several conditions: 1)
It is a UUID column* 2)
It is set to
‘Nullable = false’ 3)
It’s name starts
with ‘GlobalID’ (* is the only condition
currently used to determine if it is a global ID) Any thoughts on this in general?
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak Hi Chris, That could be. Is there a flag
that distinguishes an ESRI GUID field from other GUID fields? Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Chris
Erickson Hello, I’m looking at the ArcSDE provider, and it seems to me that
the UUID support checked in 12/8/2008 makes it so that ALL GUID fields in
ArcSDE get auto-generated on an insert, not just the ESRI GlobalID
fields. Can anyone verify this for me? We’re losing our primary
keys (and foreign keys) on inserts, and tracing through the codes, that is what
it seems to do (ArcSDEInsertCommand.cpp ~ line 210).
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||
Issue568 - ArcSDE-GuidNotWritable.patch (9K)
|
Some javascript/style in this post has been disabled (why?)
Comments…. \Providers\ArcSDE\Src\Provider\ArcSDEUtils.cpp 1)
In the following
function, use the FdoCommonOSUtil function to account for differences on
Linux/Windows… 2)
“GlobalID”.
Is this a published standard in column naming conventions from ESRI? bool
IsGlobalIDColumn(SE_COLUMN_DEF& column) { #if SDE_UNICODE return column.sde_type == SE_UUID_TYPE &&
!column.nulls_allowed && FdoCommonOSUtil::wcsnicmp((wchar_t*)column.column_name, L"GlobalID", 8) == 0; #else return column.sde_type == SE_UUID_TYPE &&
!column.nulls_allowed && FdoCommonOSUtil::strnicmp(column.column_name,
"GlobalID", 8) == 0; #endif } \Providers\ArcSDE\Src\Provider\ArcSDEFeatureCommand.h You are doing a table describe
for each string assignment. I would advise that you try and optimize this
logic. template <class FDO_COMMAND> void
ArcSDEFeatureCommand<FDO_COMMAND>::assignValue (ArcSDEConnection*
connection, SE_STREAM stream, CHAR* table, int
columnIndex, FdoPropertyDefinition* definition, FdoPropertyValue* value, bool isUnicode) { … … ... case FdoDataType_String: // Null term. Character array { //Check
to see if this is a GUID / UUID that is being set SHORT
lcolumn_count = 0; SE_COLUMN_DEF
*lcolumns = NULL; ret
= SE_table_describe
(connection->GetConnection (), table, &lcolumn_count, &lcolumns); if (ret != SE_SUCCESS) break; From:
[hidden email] [mailto:[hidden email]]
On Behalf Of Chris Erickson All, I’d like to submit the
attached patch for GUID types always getting over-written with the ArcSDE
provider. It uses the proposed logic to
determine whether it is a GlobalID or just a normal GUID field. This is a patch for the 3.4.0
branch.
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Chris
Erickson Orest, Unfortunately there isn’t
that I can see. I’m about to start working
on a fix here for our build, which I’ll submit to FDO. In my testing here, I’ve
found several things: 1)
GlobalIDs are GUIDS
where required = true. 2)
If I add a text
field to a table called GlobalID, then use ArcCatalog to ‘Add Global
IDs’, then it adds a new field called GlobalID_1. So, I think we could correctly
establish ‘GlobalIDness’, with several conditions: 1)
It is a UUID column* 2)
It is set to
‘Nullable = false’ 3)
It’s name
starts with ‘GlobalID’ (* is the only condition
currently used to determine if it is a global ID) Any thoughts on this in general?
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak Hi Chris, That could be. Is there a flag
that distinguishes an ESRI GUID field from other GUID fields? Thanks, Orest. From: [hidden email]
[mailto:[hidden email]] On Behalf Of Chris
Erickson Hello, I’m looking at the ArcSDE provider, and it seems to me
that the UUID support checked in 12/8/2008 makes it so that ALL GUID fields in
ArcSDE get auto-generated on an insert, not just the ESRI GlobalID
fields. Can anyone verify this for me? We’re losing our
primary keys (and foreign keys) on inserts, and tracing through the codes, that
is what it seems to do (ArcSDEInsertCommand.cpp ~ line 210).
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||
|
|
Some javascript/style in this post has been disabled (why?)
Inline…
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Greg Boone Comments…. \Providers\ArcSDE\Src\Provider\ArcSDEUtils.cpp 1)
In the following
function, use the FdoCommonOSUtil function to account for differences on
Linux/Windows… OK. 2)
“GlobalID”.
Is this a published standard in column naming conventions from ESRI? I can’t find a published
standard. It is from testing on our systems here. All global ID columns
start with “GlobalID”. If I add a global id to a table which
already has a string field called “GlobalID”, then it adds “GlobalID_1”.
The logic could possibly be
improved in the future, but it seems that the database / sde doesn’t
enforce, understand or have knowledge of Global IDs, and they’ve been
implemented at the application level. This stated, I’ve taken
the current logic (IsGlobalID = column.sde_type == SE_UUID_TYPE) and given it
more criteria (column.sde_type == SDE_UUID_TYPE && !nulls_allowed
&& NameStartsWith(“GlobalID”))…if more criteria could
be discerned in the future, then it could be enhanced. In any case, I
believe it is a significant improvement over the current logic, which destroys
all of my foreign keys and overwrites my primary keys for data I’m
loading. bool
IsGlobalIDColumn(SE_COLUMN_DEF& column) { #if SDE_UNICODE
return column.sde_type == SE_UUID_TYPE
&& !column.nulls_allowed && FdoCommonOSUtil::wcsnicmp((wchar_t*)column.column_name, L"GlobalID", 8) == 0; #else
return column.sde_type == SE_UUID_TYPE
&& !column.nulls_allowed && FdoCommonOSUtil::strnicmp(column.column_name,
"GlobalID", 8) == 0; #endif } \Providers\ArcSDE\Src\Provider\ArcSDEFeatureCommand.h You are
doing a table describe for each string assignment. I would advise that you try
and optimize this logic. I can take a look at doing
this. I was trying to make the changes as small as possible at the time
due to the RC status of FDO, but will try and look at this when I get a chance. template <class FDO_COMMAND> void
ArcSDEFeatureCommand<FDO_COMMAND>::assignValue (ArcSDEConnection*
connection, SE_STREAM stream, CHAR* table, int
columnIndex, FdoPropertyDefinition* definition, FdoPropertyValue* value, bool isUnicode) { … … ... case FdoDataType_String: // Null term. Character array { //Check
to see if this is a GUID / UUID that is being set
SHORT lcolumn_count = 0;
SE_COLUMN_DEF *lcolumns = NULL;
ret = SE_table_describe
(connection->GetConnection (), table, &lcolumn_count, &lcolumns);
if (ret != SE_SUCCESS)
break; From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Chris
Erickson All, I’d like to submit the
attached patch for GUID types always getting over-written with the ArcSDE
provider. It uses the proposed logic to
determine whether it is a GlobalID or just a normal GUID field. This is a patch for the 3.4.0
branch.
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Chris
Erickson Orest, Unfortunately there isn’t
that I can see. I’m about to start working
on a fix here for our build, which I’ll submit to FDO. In my testing here, I’ve
found several things: 1)
GlobalIDs are GUIDS
where required = true. 2)
If I add a text
field to a table called GlobalID, then use ArcCatalog to ‘Add Global
IDs’, then it adds a new field called GlobalID_1. So, I think we could correctly
establish ‘GlobalIDness’, with several conditions: 1)
It is a UUID column* 2)
It is set to
‘Nullable = false’ 3)
It’s name
starts with ‘GlobalID’ (* is the only condition
currently used to determine if it is a global ID) Any thoughts on this in general?
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Orest
Halustchak Hi Chris, That could be. Is there a flag
that distinguishes an ESRI GUID field from other GUID fields? Thanks, Orest. From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Chris
Erickson Hello, I’m looking at the ArcSDE provider, and it seems to me
that the UUID support checked in 12/8/2008 makes it so that ALL GUID fields in
ArcSDE get auto-generated on an insert, not just the ESRI GlobalID
fields. Can anyone verify this for me? We’re losing our
primary keys (and foreign keys) on inserts, and tracing through the codes, that
is what it seems to do (ArcSDEInsertCommand.cpp ~ line 210).
_______________________________________________ fdo-internals mailing list [hidden email] http://lists.osgeo.org/mailman/listinfo/fdo-internals |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
