[fdo-internals] RE: ArcSDE Provider issues

Fri Mar 6 16:45:26 EST 2009

Strange.. Shouldn't they use following limits?

#define SE_MAX_PROP_NAME_LEN       32  /* MAXIMUM PROPERTY NAME LENGTH */
#define SE_MAX_PROP_VAL_LEN        512 /* MAXIMUM PROPERTY VALUE LENGTH */
#define SE_MAX_DESCRIPTION_LEN     64  /* MAXIMUM LAYER DESCRIPTION LENGTH */
#define SE_MAX_FEAT_CLASS_LEN      128 /* MAXIMUM FILEINFO FEATUE CLASS 
                                          DESCRIPTION LENGTH */
#define SE_MAX_COLUMN_LEN          32  /* MAXIMUM COLUMN NAME LENGTH */
#define SE_MAX_TABLE_LEN           160 /* MAXIMUM TABLE NAME LENGTH */
#define SE_MAX_SCHEMA_TABLE_LEN    30  /* MAXIMUN TABLE 'ONLY' NAME LENGTH */
#define SE_MAX_ALIAS_LEN           32  /* MAXIMUM TABLE ALIAS LENGTH */
#define SE_MAX_ENTITY_LEN          256 /* MAXIMUM ENTITY TYPE LENGTH */
#define SE_MAX_HINT_LEN            1024/* MAXIMUM DBMS HINT LENGTH */
#define SE_MAX_OWNER_LEN           32  /* MAXIMUM TABLE OWNER NAME LENGTH */
#define SE_MAX_INDEX_LEN           160 /* MAXIMUM INDEX NAME LENGTH */
#define SE_MAX_GROUP_LEN           26  /* MAXIMUM GROUP NAME LENGTH */
#define SE_MAX_COLUMNS             256 /* MAXIMUM NUMBER OF COLUMNS */
#define SE_MAX_ANNO_TEXT_LEN       255 /* MAXIMUM ANNOTATION TEXT LENGTH */
#define SE_MAX_VERSION_LEN         64  /* MAXIMUM VERSION NAME LENGTH */
#define SE_MAX_OSNAME_LEN          64  /* MAXIMUM OPERATING SYSTEM NAME LENGTH */
#define SE_MAX_OSVERSION_LEN       128 /* MAXIMUM OPERATING SYSTEM VERSION LENGTH */
#define SE_MAX_DBMSVERSION_LEN     128 /* MAXIMUM DATABASE VERSION LENGTH */
#define SE_MAX_VERSION_INPUT_LEN   62  /* MAXIMUM USER-SUPPLIED VERSION NAME

________________________________________
From: fdo-internals-bounces at lists.osgeo.org [fdo-internals-bounces at lists.osgeo.org] On Behalf Of Chris Erickson [chris at cartopac.com]
Sent: Friday, March 06, 2009 4:40 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: ArcSDE Provider issues

Romi,
I'm talking about the string, not CLOB types.  If I create a varchar(MAX) field in SDE, it maps over to an FDO string.

chris erickson
developer
chris at cartopac.com
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Romica Dascalescu
Sent: Friday, March 06, 2009 2:38 PM
To: FDO Internals Mail List
Subject: [fdo-internals] RE: ArcSDE Provider issues

Chris,

I'm not sure whay you are trying to use that function?
You should not pass the CLOB value into a string.
You must use SE_stream_get_clob, SE_stream_get_nclob with the result you should put it into an FDO CLOB.
Also you will need to create your own conversion function from byte[]/CLOB non-Unicode into byte[]/CLOB Unicode.
I would create a conversion function which converts directly from SE_NCLOB_INFO/SE_CLOB_INFO to FDO CLOB and avoid using sde_multibyte_to_wide. These functions are not designed for huge strings

Romy.
________________________________________
From: fdo-internals-bounces at lists.osgeo.org [fdo-internals-bounces at lists.osgeo.org] On Behalf Of Chris Erickson [chris at cartopac.com]
Sent: Friday, March 06, 2009 4:23 PM
To: FDO Internals Mail List
Subject: [fdo-internals] ArcSDE Provider issues

Romi,
I've been looking at the ArcSDE provider, and it handles all string conversions using the sde_multibyte_to_wide function, which allocates the Unicode string on the stack.

If I create a varchar(max)/nvarchar(max) field in sql server with sde, these show up as string fields with a length of 65,535.  Allocating a 65k char array on the stack leads to access violation exceptions.

With your permission, I'd like to update these to use the heap and the multibyte_to_wide_noalloc routines, and pre-allocate the strings.

chris erickson
developer
chris at cartopac.com
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 1:57 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

Sure. You will have to make some arrangements with Romy or another resource to handle some of the testing.

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Chris Erickson
Sent: Friday, March 06, 2009 3:51 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

Should I submit my arcsde fix to the sandbox then for testing?

chris erickson
developer
chris at cartopac.com
970.493.9500 x 191
970.482.1485 (fax)

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 12:09 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

Please submit all your existing sandbox code submitted by Monday. At that point I will move the existing sandbox code into sandbox/3.4.0.

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 1:37 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

I also like the idea of have per-feature or per-release sandboxes rather than per-user sandboxes

ie:

sandbox/3.4.0
sandbox/3.4.0_ArcSDE93
sandbox/3.3.2_Performance

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Friday, March 06, 2009 1:26 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

Typically in this case, the developer would sandbox the latest version (let's say 3.4) and the port the changes back to 3.3. I can say that right now because the code streams for 3.3 and 3.4 are very similar. However, I have not given much thought to the whole idea of sandboxing a previous development stream. Usually such changes as that are done in a sandbox in preparation of being submitted into the trunk. I can see how use can you describe can be useful, but don't think it will be a large part of whatever sandboxing occurs.

In any case, if developers want their own sandbox, I won't stand in the way. It would be easy to move the current sandbox into a subfolder.

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Jason Birch
Sent: Friday, March 06, 2009 1:19 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

Right...

But what if someone wanted to make some relatively intrusive changes to
a provider against two different branches of FDO (say, 3.4 and 3.3) to
fix a particular defect or performance problem?

Jason

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: March-06-09 10:09 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: Random question

I think that the only item the current setup would not support is #2,
the issue of isolation. But since we are provider driven, is there a
chance we will have multiple people sandboxing the same provider? I like
the idea of a common sandbox as it allows you to immediately determine
if the changes others are working on will work with the changes you are
making without breaking the build in the trunk, etc. Sandbox changes to
FDO itself can immediately be seen and their worth be assessed by all
provider developers.

However, this is my philosophy. If you really need a sandbox for your
own development, we could set something up.
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals