How to achieve itempotency when incrementing a database column via PUT? (For example a credits-count in a purchase process)
Send a unique transaction id with every request, store all executed transaction ids and don't react to requests with a transaction id that you already saw.
Related
My domain structure is similar to this:
www.domain.com/:user_id/post/:post_id
i.e. www.domain.com/user1/post/1
I would like it to work where each user's post increments up the user's last :post_id, disregarding the actual ID of the database row, as multiple users posts will be stored there, like so:
www.domain.com/user1/post/1
www.domain.com/user1/post/2
www.domain.com/user2/post/1
www.domain.com/user2/post/2
I understand I will need a "secondary_id" column in the Post database and before committing a post to the database I will need to query the last post of the user to obtain that secondary_id to increment but I'm unsure where this logic would best reside in my app structure and what can I do to simplify/automate the process?
Also, how can I avoid race conditions on the secondary_id if this where implemented in a team environment where users could be submitting posts in between when another user has queried for the last secondary_id to increment and the second user would error out since the other user got to that secondary_id first?
When I run Custom Transaction Detail Report in QuickBooks, I can include a column called Trans #. I am not sure what it means. How is it different from Reference Number and Transaction ID?
Trans # and Transaction ID are both internal unique ID's of the transaction that are automatically generated by QuickBooks. Neither of them are something that you can edit or even see when you have the transaction itself open. I'm not sure why QuickBooks has both, other than that I don't think you can see the Transaction ID via the GUI.
Reference number is a user defined ID for the transaction (check number, "Entry No." on Journal Entries, etc.). This can be edited after the fact and doesn't have to be unique.
Hope this is what you were looking for.
I'm looking into an issue where the Refund button isn't available for orders that were placed prior to an upgrade of a client site from 1.3 to 1.7. I'm attempting to create a credit memo from Sales Order > Invoice > Credit Memo.
Drilling into the code and data, it seems that $this->getCardsStorage() is not returning any stored credit cards for order payments made prior to the upgrade. In fact, the additional_information field in the sales_flat_order_payment table is NULL for those orders - I believe that field was created in 1.4 or later.
The thing that seems odd to me is that there would be no backwards compatibility for payment data created prior to 1.4. I've done a decent bit of searching for this problem and the closest thing I can find is where people are having problems with refunds entirely after upgrading. That's not the case for me - refunds appear to be working fine for post-upgrade orders.
If it is the case that there simply is not backwards-compatibility, it would be good to at least see a bug report on it.
I posted this to the magento bug tracker: Bug #28601
That's true, there is a problem with it in 1.4 upgrades.
In 1.4 were introduced transactions and were used additional_information field, there were different field before, called additional_data, that was also serialized, but in different manner, you can look up for payment record before 1.4 and after 1.4 to compare how the data structure is changed. And when you will see the difference in data, you can create a script that will migrate old values.
Sincerely,
Ivan
UPDATE
Check the following code:
https://github.com/LokeyCoding/magento-mirror/blob/magento-1.3/app/code/core/Mage/Paygate/Model/Authorizenet.php
During authorization process, transaction id is stored in both properties:
cc_trans_id and last_trans_id. When customer perform a capture only last_trans_id get updated.
In 1.3 method getRefundTransactionId() was returning last_trans_id value.
In 1.7 the same method is looks like the following:
https://github.com/LokeyCoding/magento-mirror/blob/magento-1.7/app/code/core/Mage/Paygate/Model/Authorizenet.php
So you see it is completely rewritten!
For making your 1.7 code work for 1.3 transaction, you need to do the following for old transactions:
If last_trans_id == cc_trans_id and order has invoice, then create only capture transaction record in order_payment_transaction table.
If last_trans_id == cc_trans_id and order does not have invoice, create authorization transaction record
If last_trans_id !== cc_trans_id create 2 records, first with cc_trans_id and it will be auth transaction and second one will be a child transaction with capture type.
When you will export this old orders with such values, you will be able to refund old order from the admin.
When I save/update a project and its tasks I would like to be able to tell which tasks where saved in the transaction. For example I might create the project with a few tasks initially, several hours later I might add more tasks. I would like to know which tasks where create/updated in each transaction. I could determine this by comparing created_at fields but that seems like a bit of a hack.
Any ideas? Can I access the transaction object within the transaction and get a unique id from it? That would be ideal.
I have a Postgres database (9) that I am writing a trigger for. I want the trigger to set the modification time, and user id for a record. In Firebird you have a CONNECTIONID that you can use in a trigger, so you could add a value to a table when you connect to the database (this is a desktop application, so connections are persistent for the lifetime of the app), something like this:
UserId | ConnectionId
---------------------
544 | 3775
and then look up in the trigger that connectionid 3775 belongs to userid 544 and use 544 as the user that modified the record.
Is there anything similar I can use in Postgres?
you could use the process id. It can be retrieved with:
pg_backend_pid()
With this pid you can also use the table pg_stat_activity to get more information about the current backend, althouht you already should know everything, since you are using this backend.
Or better. Just create a serial, and retrieve one value from it for each connection:
CREATE SEQUENCE 'connectionids';
And then:
SELECT next_val('connectionids');
in each connection, to retrieve a connection unique id.
One way is to use the custom_variable_classes configuration option. It appears to be designed to allow the configuration of add-on modules, but can also be used to store arbitrary values in the current database session.
Something along the lines of the following needs to be added to postgresql.conf:
custom_variable_classes = 'local'
When you first connect to the database you can store whatever information you require in the custom class, like so:
SET local.userid = 'foobar';
And later in on you can retrieve this value with the current_setting() function:
SELECT current_setting('local.userid');
Adding an entry to a log table might look something like this:
INSERT INTO audit_log VALUES (now(), current_setting('local.userid'), ...)
While it may work for your desktop use case, note that process ID numbers do rollover (32768 is a common upper limit), so using them as a unique key to identify a user can run into problems. If you ever end up with leftover data from a previous session in the table that's tracking user->process mapping, that can collide with newer connections assigned the same process id once it's rolled over. It may be sufficient for your app to just make sure you aggressively clean out old mapping entries, perhaps at startup time given how you've described its operation.
To avoid this problem in general, you need to make a connection key that includes an additional bit of information, such as when the session started:
SELECT procpid,backend_start FROM pg_stat_activity WHERE procpid=pg_backend_pid();
That has to iterate over all of the connections active at the time to compute, so it does add a bit of overhead. It's possible to execute that a bit more efficiently starting in PostgreSQL 8.4:
SELECT procpid,backend_start FROM pg_stat_get_activity(pg_backend_pid());
But that only really matters if you have a large number of connections active at once.
Use current_user if you need the database user (I'm not sure that's what you want by reading your question).