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

Thu May 26 12:26:11 EDT 2011

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