Page 1 of 1

Square peg, round hole

Posted: 26.10.2006, 19:14
by CharlesMcAllister
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!

Posted: 26.10.2006, 21:37
by mdaems
Hi Charles,

Have you tried to set CachedUpdates (ZQuery Component) to true? Then you should be able to call ApplyUpdates to send all changes at once to the server. (Or CancelUpdates to undo your change)

Mark

Posted: 27.10.2006, 00:57
by CharlesMcAllister
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?

Posted: 27.10.2006, 15:11
by CharlesMcAllister
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!

Posted: 27.10.2006, 16:33
by CharlesMcAllister
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!

Posted: 29.10.2006, 22:51
by fduenas
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?

Posted: 29.10.2006, 23:33
by CharlesMcAllister
Yes that would be fine with me.
I can write that code and e-mail you a diff if you like.
I understand there is a feature freeze on 6.6 now. Is there work started on 6.7 yet?

Posted: 30.10.2006, 02:17
by fduenas
No. What we're doing is to make a stable version of 6.6. then after that release we can start 6.7 version or 7.0.

It could be great if you write the code but you should do the changes to the latest testing branch so the patch can be applied correctly.