Maybe this is a pure Geotools issue, but it's also very related to Geoserver. A year ago, there has been discussion how Geoserver should acquire the values for fid's when inserting features (and in that case it was on an Oracle database). The idea was to have a few options for genration of fid's (e.g. a sequence is specified in the database, some trigger is used or use some algorithm that inserts the max-value), that a user could configure.
I can't really find what has been implemented on this, but as far as I understand from the Geotools sources, the max-value of all current features is used now to get the next value for the FID. This resembles a sequence somehow, but in a way it is dangerous. Because when multiple users send a transaction, it can cause new fids not to be unique (or is that accounted for?). However, I also noticed in org.geotools.data.jdbc.JDBCFeatureWriter in the fid_exp-stuff (sorry for calling it that way), that there is some check done if the fid-column is AutoIncrement, and if so, that a null-value is inserted for the fid, so that the database generates the value.
Can anyone tell me whether this is used by Geoserver (I'm especially interested how Geoserver deals with this on an Oracle database)? Because in org.geotools.data.jdbc.JDBCDataStore.JDBCFeatureWriter, there still is the method write(), which only checks the max-value....
In short, can anyone tell me how Geoserver generates new fids nowadays?
This issue has been "solved" in the design of Geotools - and is available in Geotools 2.1. GoeServer development has just switched over to 2.1 - I think GeoServer 1.3 when it is available will be the first to make use of this capability.
My project, uDig, is also based on GeoTools 2.1 and have just been applying some fixes to the Postgis Datastore to make fid generation (and thus editing) work by default.
Cheers,
Jody
Hi list,
Maybe this is a pure Geotools issue, but it's also very related to Geoserver. A year ago, there has been discussion how Geoserver should acquire the values for fid's when inserting features (and in that case it was on an Oracle database). The idea was to have a few options for genration of fid's (e.g. a sequence is specified in the database, some trigger is used or use some algorithm that inserts the max-value), that a user could configure.
I can't really find what has been implemented on this, but as far as I understand from the Geotools sources, the max-value of all current features is used now to get the next value for the FID. This resembles a sequence somehow, but in a way it is dangerous. Because when multiple users send a transaction, it can cause new fids not to be unique (or is that accounted for?). However, I also noticed in org.geotools.data.jdbc.JDBCFeatureWriter in the fid_exp-stuff (sorry for calling it that way), that there is some check done if the fid-column is AutoIncrement, and if so, that a null-value is inserted for the fid, so that the database generates the value.
Can anyone tell me whether this is used by Geoserver (I'm especially interested how Geoserver deals with this on an Oracle database)? Because in org.geotools.data.jdbc.JDBCDataStore.JDBCFeatureWriter, there still is the method write(), which only checks the max-value....
In short, can anyone tell me how Geoserver generates new fids nowadays?
This issue has been "solved" in the design of Geotools - and is
available in Geotools 2.1. GoeServer development has just switched over
to 2.1 - I think GeoServer 1.3 when it is available will be the first to
make use of this capability.
Huh? Can you give details on how it is 'solved'? Are you sure it's not
on 2.0? I'm pretty sure all the fid generation stuff made it in to 2.0.
My project, uDig, is also based on GeoTools 2.1 and have just been
applying some fixes to the Postgis Datastore to make fid generation (and
thus editing) work by default.
Thijs is interested in Oracle. Is uDig supporting oracle jody? And what
is the nature of your fixes?
Also, I don't think oracle in 2.0 uses the jdbc feature writer any more.
I think it uses the text feature writer. I'll dig into it next week to
figure out how it's working these days. But I'm _pretty_ sure that oracle
in geoserver does make use of the auto increment for fid generation if it
is available. I think that may have been one of the reasons I switched
over to a text feature writer (though I could be wrong about that).
Chris
Cheers,
Jody
> Hi list,
>
> Maybe this is a pure Geotools issue, but it's also very related to
> Geoserver. A year ago, there has been discussion how Geoserver should
> acquire the values for fid's when inserting features (and in that case
> it was on an Oracle database). The idea was to have a few options for
> genration of fid's (e.g. a sequence is specified in the database, some
> trigger is used or use some algorithm that inserts the max-value),
> that a user could configure.
>
> I can't really find what has been implemented on this, but as far as I
> understand from the Geotools sources, the max-value of all current
> features is used now to get the next value for the FID. This resembles
> a sequence somehow, but in a way it is dangerous. Because when
> multiple users send a transaction, it can cause new fids not to be
> unique (or is that accounted for?). However, I also noticed in
> org.geotools.data.jdbc.JDBCFeatureWriter in the fid_exp-stuff (sorry
> for calling it that way), that there is some check done if the
> fid-column is AutoIncrement, and if so, that a null-value is inserted
> for the fid, so that the database generates the value.
>
> Can anyone tell me whether this is used by Geoserver (I'm especially
> interested how Geoserver deals with this on an Oracle database)?
> Because in org.geotools.data.jdbc.JDBCDataStore.JDBCFeatureWriter,
> there still is the method write(), which only checks the max-value....
>
> In short, can anyone tell me how Geoserver generates new fids nowadays?
>
> Thanks!
>
> Best regards,
> Thijs
>
>
>
>
>
>
> ------------------------------------------------------------
> Geodan IT b.v.
> President Kennedylaan 1
> 1079 MB Amsterdam (NL)
> ------------------------------------------------------------
> Tel: +31 (0)20 - 5711 311
> Fax: +31 (0)20 - 5711 333
> ------------------------------------------------------------
> E-mail: thijs.brentjens@anonymised.com
> Website: www.geodan.nl
> Disclaimer: www.geodan.nl/disclaimer
> ------------------------------------------------------------
>
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
Jesse and Jody were working on this. From what I can gather, the
FidMappers for the specific datastores were not always being used ...
basically they forced the datastore's version to be used if it existed.
This work was all completed in context with PostGis.
Oracle is one of the datastores we intend to make use of in the future,
but unfortunately it will not be part of our next release as this has
not yet been tested in uDig.
David
On Fri, 2005-02-11 at 12:11, Chris Holmes wrote:
> Hi Thijs Brentjens:
>
> This issue has been "solved" in the design of Geotools - and is
> available in Geotools 2.1. GoeServer development has just switched over
> to 2.1 - I think GeoServer 1.3 when it is available will be the first to
> make use of this capability.
Huh? Can you give details on how it is 'solved'? Are you sure it's not
on 2.0? I'm pretty sure all the fid generation stuff made it in to 2.0.
> My project, uDig, is also based on GeoTools 2.1 and have just been
> applying some fixes to the Postgis Datastore to make fid generation (and
> thus editing) work by default.
Thijs is interested in Oracle. Is uDig supporting oracle jody? And what
is the nature of your fixes?
Also, I don't think oracle in 2.0 uses the jdbc feature writer any more.
I think it uses the text feature writer. I'll dig into it next week to
figure out how it's working these days. But I'm _pretty_ sure that oracle
in geoserver does make use of the auto increment for fid generation if it
is available. I think that may have been one of the reasons I switched
over to a text feature writer (though I could be wrong about that).
Chris
>
> Cheers,
> Jody
>
> > Hi list,
> >
> > Maybe this is a pure Geotools issue, but it's also very related to
> > Geoserver. A year ago, there has been discussion how Geoserver should
> > acquire the values for fid's when inserting features (and in that case
> > it was on an Oracle database). The idea was to have a few options for
> > genration of fid's (e.g. a sequence is specified in the database, some
> > trigger is used or use some algorithm that inserts the max-value),
> > that a user could configure.
> >
> > I can't really find what has been implemented on this, but as far as I
> > understand from the Geotools sources, the max-value of all current
> > features is used now to get the next value for the FID. This resembles
> > a sequence somehow, but in a way it is dangerous. Because when
> > multiple users send a transaction, it can cause new fids not to be
> > unique (or is that accounted for?). However, I also noticed in
> > org.geotools.data.jdbc.JDBCFeatureWriter in the fid_exp-stuff (sorry
> > for calling it that way), that there is some check done if the
> > fid-column is AutoIncrement, and if so, that a null-value is inserted
> > for the fid, so that the database generates the value.
> >
> > Can anyone tell me whether this is used by Geoserver (I'm especially
> > interested how Geoserver deals with this on an Oracle database)?
> > Because in org.geotools.data.jdbc.JDBCDataStore.JDBCFeatureWriter,
> > there still is the method write(), which only checks the max-value....
> >
> > In short, can anyone tell me how Geoserver generates new fids nowadays?
> >
> > Thanks!
> >
> > Best regards,
> > Thijs
> >
> >
> >
> >
> >
> >
> > ------------------------------------------------------------
> > Geodan IT b.v.
> > President Kennedylaan 1
> > 1079 MB Amsterdam (NL)
> > ------------------------------------------------------------
> > Tel: +31 (0)20 - 5711 311
> > Fax: +31 (0)20 - 5711 333
> > ------------------------------------------------------------
> > E-mail: thijs.brentjens@anonymised.com
> > Website: www.geodan.nl
> > Disclaimer: www.geodan.nl/disclaimer
> > ------------------------------------------------------------
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF email is sponsored by - The IT Product Guide
> > Read honest & candid reviews on hundreds of IT Products from real users.
> > Discover which products truly live up to the hype. Start reading now.
> > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> > _______________________________________________
> > Geoserver-devel mailing list
> > Geoserver-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
Thanks for your answers. They are quite helpful to me, since it is important for us to know how fids are generated. The database we're using Geoserver on now, is also edited directly (without a WFS). And it would be nice if Oracle is supported in uDig directly, but until that, one could use a WFS to access an Oracle database as well :). Anyway, thanks!
Thijs
At 21:27 11-2-2005, David Zwiers wrote:
Chris, Thijs,
Jesse and Jody were working on this. From what I can gather, the
FidMappers for the specific datastores were not always being used ...
basically they forced the datastore's version to be used if it existed.
This work was all completed in context with PostGis.
Oracle is one of the datastores we intend to make use of in the future,
but unfortunately it will not be part of our next release as this has
not yet been tested in uDig.
David
On Fri, 2005-02-11 at 12:11, Chris Holmes wrote:
> > Hi Thijs Brentjens:
> >
> > This issue has been "solved" in the design of Geotools - and is
> > available in Geotools 2.1. GoeServer development has just switched over
> > to 2.1 - I think GeoServer 1.3 when it is available will be the first to
> > make use of this capability.
> Huh? Can you give details on how it is 'solved'? Are you sure it's not
> on 2.0? I'm pretty sure all the fid generation stuff made it in to 2.0.
>
> > My project, uDig, is also based on GeoTools 2.1 and have just been
> > applying some fixes to the Postgis Datastore to make fid generation (and
> > thus editing) work by default.
> Thijs is interested in Oracle. Is uDig supporting oracle jody? And what
> is the nature of your fixes?
>
> Also, I don't think oracle in 2.0 uses the jdbc feature writer any more.
> I think it uses the text feature writer. I'll dig into it next week to
> figure out how it's working these days. But I'm _pretty_ sure that oracle
> in geoserver does make use of the auto increment for fid generation if it
> is available. I think that may have been one of the reasons I switched
> over to a text feature writer (though I could be wrong about that).
>
> Chris
>
> >
> > Cheers,
> > Jody
> >
> > > Hi list,
> > >
> > > Maybe this is a pure Geotools issue, but it's also very related to
> > > Geoserver. A year ago, there has been discussion how Geoserver should
> > > acquire the values for fid's when inserting features (and in that case
> > > it was on an Oracle database). The idea was to have a few options for
> > > genration of fid's (e.g. a sequence is specified in the database, some
> > > trigger is used or use some algorithm that inserts the max-value),
> > > that a user could configure.
> > >
> > > I can't really find what has been implemented on this, but as far as I
> > > understand from the Geotools sources, the max-value of all current
> > > features is used now to get the next value for the FID. This resembles
> > > a sequence somehow, but in a way it is dangerous. Because when
> > > multiple users send a transaction, it can cause new fids not to be
> > > unique (or is that accounted for?). However, I also noticed in
> > > org.geotools.data.jdbc.JDBCFeatureWriter in the fid_exp-stuff (sorry
> > > for calling it that way), that there is some check done if the
> > > fid-column is AutoIncrement, and if so, that a null-value is inserted
> > > for the fid, so that the database generates the value.
> > >
> > > Can anyone tell me whether this is used by Geoserver (I'm especially
> > > interested how Geoserver deals with this on an Oracle database)?
> > > Because in org.geotools.data.jdbc.JDBCDataStore.JDBCFeatureWriter,
> > > there still is the method write(), which only checks the max-value....
> > >
> > > In short, can anyone tell me how Geoserver generates new fids nowadays?
> > >
> > > Thanks!
> > >
> > > Best regards,
> > > Thijs
> > >
> > > ------------------------------------------------------------
> > > Geodan IT b.v.
> > > President Kennedylaan 1
> > > 1079 MB Amsterdam (NL)
> > > ------------------------------------------------------------
> > > Tel: +31 (0)20 - 5711 311
> > > Fax: +31 (0)20 - 5711 333
> > > ------------------------------------------------------------
> > > E-mail: thijs.brentjens@anonymised.com
> > > Website: www.geodan.nl
> > > Disclaimer: www.geodan.nl/disclaimer
> > > ------------------------------------------------------------
> > >