[fdo-internals] RE: FDO RFC 61 ready for review

Sun May 29 22:28:18 EDT 2011

Hi Dan,

Here are my comments:

a)I think release save point is not available for all providers. For example, SQL Server spatial and Oracle does not support "RELEASE" command.
Perhaps we should leave the implementation as unsupported or empty for these providers?
b) I think it is reasonable, better than my original idea of throwing an exception if a save point name already exists.
c) Yes, but that would also add complexity. Well what if the save points collection is out of sync with the save point stack of the underlying database(as Tarian said)?  I would prefer leaving it to API users to handle.

Thanks, 
Sam 

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Monday, May 30, 2011 9:42 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 61 ready for review

Hi,

a) I think the proposed API is missing the RELEASE method. What happens with a save point when never used, what is its life span? How various RDBMS behave in this regard?

See also: http://www.sqlite.org/lang_savepoint.html

b) There is no warranty the save point creation will succeed with a given name. Therefore I suggest this change, where the user proposes a prefix and gets back a name (maybe mangled):

	FDO_API virtual FdoString* AddSavePoint(FdoString* savePointPrefix) = 0;

c) leaving the logic to the application means the API is less friendly. The proposed API works fine for one save point created locally but for multiple save points spread over various methods, functions and modules I think would be useful to have a way to get back the save points.

(I'm running out of cents)

Thanks,
Dan.

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Sam Wang
Sent: Thursday, May 26, 2011 9:54 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 61 ready for review

Hi Dan,

I tend to agree with Haris and Traian, as I have mentioned in the previous threads, "users of this API should be aware of the order of save points and will not roll back to an invalid save point", that the logic should be left to application level to handle.

@Tarian, I found that API "SetTransaction" is empty implementation in nearly all providers. So I think it this statement can be ignored, without it transaction will also work properly.

Thanks,
Sam

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Friday, May 27, 2011 12:26 AM
To: 'FDO Internals Mail List'
Subject: RE: [fdo-internals] RE: FDO RFC 61 ready for review

Hi Dan, 

In the SQLite docs, I can't find if there is such a table in SQLite, which is one of the providers that this RFC is supposed to apply to... 

But, there are other problems with SQLite as well. For example the example given in the RFC, where it does deleteCommand->SetTransaction() will not automatically work with the SQLite provider, given the current implementation of SetTransaction:

virtual void SetTransaction(FdoITransaction* value) { }

That provider is simply not designed with transactionality in mind, and implying so via the savepoint capability would be misleading unless significant work is put into supporting transactions throughout its commands, etc.

Traian

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
Sent: Thursday, May 26, 2011 12:01 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 61 ready for review

I understand Traian's concern.

My original point was around the fact that it's unusual to set something but not being able to get it back. See this API for example:

http://download.oracle.com/javase/1.4.2/docs/api/java/sql/Savepoint.html

Apparently Oracle stores the save points into ORADFCSAVPT table. I'm confident that any other RDBMS supporting save points has something similar.
Hence the list is not maintained by the provider (which probably I wrongly implied).

Dan.

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Greg Boone
Sent: Thursday, May 26, 2011 11:42 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] RE: FDO RFC 61 ready for review

Yes, I agree with Haris and Traian. 

Greg

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Traian Stanev
Sent: Thursday, May 26, 2011 11:35 AM
To: 'FDO Internals Mail List'
Subject: RE: [fdo-internals] RE: FDO RFC 61 ready for review

Yes, I agree with that. That list, if maintained manually by the provider layer, would be in danger of going out of sync with the underlying database savepoint stack anyway, so it should be pushed out to the application to maintain at its own risk. 

Traian

-----Original Message-----
From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Haris Kurtagic
Sent: Thursday, May 26, 2011 3:24 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] RE: FDO RFC 61 ready for review

Hi,

For function 'GetAvailableSavePoints' I am not aware there is something on DB side that supports it ?

SavePoints are part of application logic, when to add them and rollback ...
I don't think provider should be bothering with keeping updated on savepoint list.

Haris

On Thu, May 26, 2011 at 8:46 AM, Sam Wang <Sam.Wang at autodesk.com> wrote:
> Hi Dan,
>
> Thanks for  your comments.  I have updated the RFC accordingly.
> In order to use FdoNamedCollection which requires that the template argument "OBJ" class must provide method GetName() and CanSetName(). So a new class named FdoSavePoint has to be defined to be used as the element type for the collection.
>
> Thanks,
> Sam
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
> Sent: Wednesday, May 25, 2011 10:03 PM
> To: FDO Internals Mail List
> Subject: [fdo-internals] RE: FDO RFC 61 ready for review
>
> Hi,
>
> First, the collection has to be a FdoNamedCollection to ensure the uniqueness of the names.
>
> Secondly, it would be more consistent with the FDO API to get this collection from the transaction object and then add to it.
>
> Third, about 'invalid save points': once the user has this collection it's less likely he will rollback to a invalid savepoint. Meaning also the FDO exception you indicate below will not be needed.
>
> In any case, the proposed RFC is missing a section where the usage is illustrated.
>
> My 2c.
>
> Dan.
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Sam Wang
> Sent: Tuesday, May 24, 2011 11:09 PM
> To: FDO Internals Mail List
> Subject: [fdo-internals] RE: FDO RFC 61 ready for review
>
> Hi Dan,
>
> I think this can be maintained internally. Once user rolls back to a specific save point, all the save points defined after it will be invalid. Thus for example, if we rolls back to save point #3, and later user rolls back to #4, an FDO exception should be thrown to indicate that save point #4 is no longer valid due to the rollback of save point #3.
>
> If we are to provide an API to get the list of available save points, I propose that we add an API prototype like:
> virtual FdoStringCollection* GetAvailableSavePoints() = 0;
>
> However my opinion is that users of this API should be aware of the order of save point definition and will not roll back to an invalid save point. So I think this API is more likely to utilize user(even if they had this utility method, they still can pass an invalid save point to rollback method), and I would regard it more like an option than necessary.
>
> Thanks,
> Sam
>
> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
> Sent: Wednesday, May 25, 2011 10:07 AM
> To: FDO Internals Mail List
> Subject: [fdo-internals] RE: FDO RFC 61 ready for review
>
> Hi Sam,
>
> My point is that the proposed API alllows for an a arbitrary number of save points. Meaning the user needs to keep track of them. And no, "release save point" is not necessary since I assume RollBack() is doing this.
>
> Please let me understand: a collection of save points is actually a stack, right? If so then once the user rolls back to the save point #N (where N is the index in the stack) then all the save points with a higher number are dissolved. Therefore I believe a method to get the remaining save points is necessary.
>
> Thanks,
> Dan.
> ________________________________________
> From: fdo-internals-bounces at lists.osgeo.org
> [fdo-internals-bounces at lists.osgeo.org] on behalf of Sam Wang 
> [Sam.Wang at autodesk.com]
> Sent: Tuesday, May 24, 2011 6:44 PM
> To: FDO Internals Mail List
> Subject: [fdo-internals] RE: FDO RFC 61 ready for review
>
> Hi Dan,
>
> If you look into the RFC you will find that there is already an API proposed to roll back to a save point : FdoITransaction::RollBack(FdoString* savePointName). Do you mean that should be additional API to do something like "release save point" ?
>
> Thanks,
> Sam
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Dan Stoica
> Sent: Tuesday, May 24, 2011 10:59 PM
> To: FDO Internals Mail List
> Subject: [fdo-internals] RE: FDO RFC 61 ready for review
>
> Hi,
>
> Shouldn't the API include a method to get back all the added save points? This would allow to programmatically rollback to a save point, I think.
>
> Thanks,
> Dan.
>
> From: fdo-internals-bounces at lists.osgeo.org
> [mailto:fdo-internals-bounces at lists.osgeo.org] On Behalf Of Sam Wang
> Sent: Sunday, May 22, 2011 9:42 PM
> To: fdo-internals at lists.osgeo.org
> Subject: [fdo-internals] FDO RFC 61 ready for review
>
> Hi experts,
>
> FDO RFC 61 is now ready for review. You can find it at
> http://trac.osgeo.org/fdo/wiki/FDORfc61
>
> Thanks,
> Sam
> _______________________________________________
> 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
_______________________________________________
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