[fdo-internals] PostGIS ticket 106 question

[Haris Kurtagic]

I wasn't saying that it should be made dependent of metadata. I was
saying that spec looks like written with case of metadata in mind.

I don't see reason if database allows delete table with or without data
in it that provider shouldn't. I dont like the idea that provider is
smarter than database without clear reason.

Thank you for Delete command remainder.

Haris

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Orest
Halustchak
Sent: Wednesday, February 20, 2008 7:08 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] PostGIS ticket 106 question

Well, the FDO spec is fairly explicit in this case saying that the class
must not have any instance data. It doesn't matter whether there is
added metadata or not. If we made it depend on whether metadata existed
or was determined by reverse engineering, then this operation would be
somewhat unpredictable for a caller.

The FDO Delete command can be used to delete all objects of a class by
not specifying a filter.

Thanks,
Orest.

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris
Kurtagic
Sent: Wednesday, February 20, 2008 1:17 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] PostGIS ticket 106 question

I think it is not bug.
I believe differences in thinking come from difference that some
providers use metadata to describe FDO class some don't. In case when
provider uses metadata to describe FDO class then delete class could
have a differenet meaning than in case provider matches tables directly
to class.
If provider is not using metadata than there is nothing to do with
delete class command except to delete table. And considering consistency
of data etc. it is up to database to say if it is ok to delete not the
provider.

BTW: We don't have command do delete all data in FDO ? ( not counting
executing sql )

Haris

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org
[mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Bruno Scott
Sent: Wednesday, February 20, 2008 6:19 PM
To: fdo-internals at lists.osgeo.org
Subject: RE: [fdo-internals] PostGIS ticket 106 question


So this meens that all these providers have a defect?
  Sdf
  Shp
  Autodesk Oracle
  King Oracle
  MySQL
  Autodesk SqlServer
Because they allow dropping table with data in it.
Bruno


Robert Fortin wrote:
>
> Oups!  Error...
>
> Correction: So as soon as there is data you ***can't*** delete the
> table...
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Robert
Fortin
> Sent: Wednesday, February 20, 2008 11:42 AM
> To: FDO Internals Mail List
> Subject: RE: [fdo-internals] PostGIS ticket 106 question
>
> At first I thought that it was up to the provider to decide in what
> circumstance a class (table) could be deleted.
> Well, not really...
>
> The documentation is not always clear and detailed but in this case
the
> FDO spec for ApplySchema is pretty clear (extract from
> http://fdo.osgeo.org/files/fdo/docs/FDO_API/index.htm FdoIApplySchema
> Class Reference)
>
> If schema changes include deletion of classes or the schema itself,
then
> those classes (or the schema, if it is marked as deleted) must not
contain
> any instance data. If they do, an exception will be thrown.
>
> So as soon as there is data you can delete the table.  You must empty
the
> table before you can delete it.
>
> RF
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Mateusz
Loskot
> Sent: Wednesday, February 20, 2008 11:22 AM
> To: FDO Internals Mail List
> Subject: Re: [fdo-internals] PostGIS ticket 106 question
>
> Bruno Scott wrote:
>> As we are about to fix that one
>>     http://trac.osgeo.org/fdo/ticket/106
>> Just want to check with you guys because there is a debate on that
one
>>
>>
http://www.nabble.com/Defects-in-PostGIS-provider-to12280094s18162.html#
a12295194
>>
>> For my point of view, as PostGIS allow dropping table with the SQL
"Drop
>> table" it's safe to do so.
>
> Bruno,
>
> It should be safe at least in current version of PostGIS provider,
> I mean where a feature class mapping to physical table is simple
> one-to-one relation, but if in future there is more complex mapping
> available then simple DROP TABLE may break data consistency.
>
> Cheers
> --
> Mateusz Loskot
> http://mateusz.loskot.net
> _______________________________________________
> 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
>
>

--
View this message in context:
http://www.nabble.com/PostGIS-ticket-106-question-tp15591249s18162p15593
982.html
Sent from the fdo-internals mailing list archive at Nabble.com.

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals

No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.20.8/1288 - Release Date:
2/19/2008 8:47 PM

_______________________________________________
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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.20.8/1288 - Release Date:
2/19/2008 8:47 PM