Square peg, round hole
Moderators: gto, cipto_kh, EgonHugeist, mdaems
-
- Fresh Boarder
- Posts: 19
- Joined: 25.10.2006, 19:25
Square peg, round hole
I need to be able to update more than one row in a result set before updates are applied. Is there a component in ZeosLib that will let me do this?
If there isn't a component, is there a reason (other than time and effort) that this capability should not exist? For instance, would this capability require excessive memory use?
Would anyone else find this capability useful? Should this be a part of ZeosLib?
I've attached a sample project that describes the problem I am trying to solve. The steps to reproduce are at the top of frmDomainTest.pas.
Thanks for your attention!
If there isn't a component, is there a reason (other than time and effort) that this capability should not exist? For instance, would this capability require excessive memory use?
Would anyone else find this capability useful? Should this be a part of ZeosLib?
I've attached a sample project that describes the problem I am trying to solve. The steps to reproduce are at the top of frmDomainTest.pas.
Thanks for your attention!
You do not have the required permissions to view the files attached to this post.
-
- Fresh Boarder
- Posts: 19
- Joined: 25.10.2006, 19:25
In the example code, I need to be able to save each domain object individually, regardless of whether or not other domain objects have modified their row data.
When this domain object is saved, it is actually committed to the DB, however at the same time there may exist other domain objects that have modified their data, but do not yet want to commit to the DB.
Can I modifiy rows in a TZQuery and commit each row individually?
When this domain object is saved, it is actually committed to the DB, however at the same time there may exist other domain objects that have modified their data, but do not yet want to commit to the DB.
Can I modifiy rows in a TZQuery and commit each row individually?
-
- Fresh Boarder
- Posts: 19
- Joined: 25.10.2006, 19:25
TZQuery is probably more than what i need.
I can see that the TZCachedResultSet has a CachedUpdates property.
If I set that to true, then it satisfies most of the requirements in the example program.
However I still need a way to save/commit each domain object independently. I'll look at it some more, but I think i'm getting close!
I can see that the TZCachedResultSet has a CachedUpdates property.
If I set that to true, then it satisfies most of the requirements in the example program.
However I still need a way to save/commit each domain object independently. I'll look at it some more, but I think i'm getting close!
-
- Fresh Boarder
- Posts: 19
- Joined: 25.10.2006, 19:25
There are several ways I can get ZeosLib to let me commit one row at a time in a TZCachedResultSet.
Proposal #1: Add a new method to TZCachedResultSet, called CommitRow, which does basically what PostUpdates does, only it does it for the selected row. It would commit regardless of whether or not CachedUpdates was set to True. (this is what i've done for now in my copy of the source)
Proposal #2: Add hooks into Zeos so that i can supply a custom TZCachedResultSet class to the various GetCachedResultSet methods. This would allow me to make my own TZCachedResultSet descendant which would have the CommitRow method, and Zeos would use this class at appropriate times.
Proposal #3: Add an event to TZCachedResultSet which would be invoked within PostUpdates. This event would have an AllowUpdate parameter that one could use to avoid committing certain rows. Personally I like this proposal the least, as it is not particularly efficient.
Will the admins of Zeos accept any of these proposed solutions provided I make the necessary changes?
Thanks for help!
Proposal #1: Add a new method to TZCachedResultSet, called CommitRow, which does basically what PostUpdates does, only it does it for the selected row. It would commit regardless of whether or not CachedUpdates was set to True. (this is what i've done for now in my copy of the source)
Proposal #2: Add hooks into Zeos so that i can supply a custom TZCachedResultSet class to the various GetCachedResultSet methods. This would allow me to make my own TZCachedResultSet descendant which would have the CommitRow method, and Zeos would use this class at appropriate times.
Proposal #3: Add an event to TZCachedResultSet which would be invoked within PostUpdates. This event would have an AllowUpdate parameter that one could use to avoid committing certain rows. Personally I like this proposal the least, as it is not particularly efficient.
Will the admins of Zeos accept any of these proposed solutions provided I make the necessary changes?
Thanks for help!
I think we can do this a better way.
to add a row parameter to the ApplyUpdates and to cancelUpdates, like the one in ClientDataSet. By default the value of the row will be 0, so if we send TZQuery.ApplyUpdates(0) or TZQuery.ApplyUpdates it will apply all updates as usual and if we call TZQuery.applyUpdates(1) it will applyupdates of row 1.
what do you think?
to add a row parameter to the ApplyUpdates and to cancelUpdates, like the one in ClientDataSet. By default the value of the row will be 0, so if we send TZQuery.ApplyUpdates(0) or TZQuery.ApplyUpdates it will apply all updates as usual and if we call TZQuery.applyUpdates(1) it will applyupdates of row 1.
what do you think?
-
- Fresh Boarder
- Posts: 19
- Joined: 25.10.2006, 19:25