Bug #8729
Improve Finisher DB - GP inserted_uid
| Status: | Resolved | Start date: | 2010-07-07 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | Fabien Udriot | % Done: | 100% |
|
| Category: | Finisher | |||
| Target version: | Beta 5 (v0.9.8) | |||
| Votes: | 0 |
Description
I have got a special use case.
I have sequence of two Finisher DB where I create a record in a first Finisher DB. Afterward, I need to update a field of this record with second Finisher DB. It is not possible right now because for the second Finisher the uid is not transmitted. I would like to retrieve this value from the "inserted_uid" field, though.
Check out the attached patch.
Associated revisions
[BUGFIX] formhandler: Add EnableFields to Validator "IsNotInDBTable" - resolves #8729
[BUGFIX] formhandler: Add EnableFields to Validator "IsNotInDBTable" - resolves #8729
[+BUGFIX] formhandler: Improve Finisher DB - GP inserted_uid - resolves #8729
[+BUGFIX] formhandler: Improve Finisher DB - GP inserted_uid - resolves #8729
History
Updated by Mathias Bolt Lesniak almost 3 years ago
Thanks Fabien! I was in exactly the same situation right now. This feature is a must!
Updated by Reinhard Führicht almost 3 years ago
Just a thought:
What about allowing the TypoScript settings for Finisher_DB to be cObjects?
This would mean changing something like:
$this->key = $this->settings['key'];
if(!$this->key) {
$this->key = 'uid';
}
to:
$this->key = Tx_Formhandler_StaticFuncs::getSingle($this->settings, 'key');
if(!$this->key) {
$this->key = 'uid';
}
I didn't test this, but this would enable many more possibilities than a hard coded fallback to $this->gp['inserted_uid'].
What do you think?
Updated by Fabien Udriot almost 3 years ago
Yes, it can be a good idea to implement a stdWrap on setting "key".
But, notice my patch is more about the value of "key" itself rather than about the name. At the moment it is not possible to retrieve the inserted_uid after an INSERT.
My patch applies after line 175 in Finisher DB (or around).
If we would like to provide more flexibility, we should introduce a new setting key like "key_value" and have following code.
$uid = Tx_Formhandler_StaticFuncs::getSingle($this->settings, 'key_value');
if(!$uid) {
$uid = $this->gp[$this->key];
}
Updated by Reinhard Führicht almost 3 years ago
OK, now I get it.
You are right. We would need a new setting for the key value. I would prefer the solution with a new setting.
Updated by Fabien Udriot almost 3 years ago
OK for me. So here is v2 of the patch.
Index: Classes/Finisher/Tx_Formhandler_Finisher_DB.php
===================================================================
--- Classes/Finisher/Tx_Formhandler_Finisher_DB.php (revision 35609)
+++ Classes/Finisher/Tx_Formhandler_Finisher_DB.php (working copy)
@@ -172,7 +172,11 @@
} else {
//check if uid of record to update is in GP
- $uid = $this->gp[$this->key];
+ $uid = Tx_Formhandler_StaticFuncs::getSingle($this->settings, 'key_value');
+ if(!$uid) {
+ $uid = $this->gp[$this->key];
+ }
+
if($uid) {
$query = $GLOBALS['TYPO3_DB']->UPDATEquery($this->table, $this->key . '=' . $uid, $queryFields);
Tx_Formhandler_StaticFuncs::debugMessage('sql_request', $query);
@@ -199,7 +203,7 @@
}
//set primary key field
- $this->key = $this->settings['key'];
+ $this->key = Tx_Formhandler_StaticFuncs::getSingle($this->settings, 'key');
if(!$this->key) {
$this->key = 'uid';
}
I have tested it successfully with this finisher
# Insert the data into the database
2.class = Tx_Formhandler_Finisher_DB
2.config {
updateInsteadOfInsert = 1
table = tx_addresses_domain_model_person
key = uid
key_value = TEXT
key_value.data = GPvar:formhandler|inserted_uid
fields {
fe_user {
mapping = tx_addresses_domain_model_person_inserted_uid
}
}
}
Ready for commit? It has been a long time now... :D
Updated by Fabien Udriot almost 3 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Applied in changeset r35714.
Updated by Fabien Udriot almost 3 years ago
Weird... the issue was automatically set to "resolved" and not by me. I think it is due because I got confused with the last comment in my commit and mentioned the wrong bug ID. It think Redmine has become too intelligent.
Anyway, I had to commit the code to avoid further confusion and to override what Redmine put automatically along the issue.
If anything is wrong with changeset r35722, let me know, I will take care of it.