These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

Wallet Journal and Incursion Bounty Surcharge
Author
Previous Topic Next Topic
Captain Xero
3 Star Industries
#1 - 2011-10-03 20:13:08 UTC
Hi,

I recently hit a situation that I haven't seen before. A corp mate was ratting in an incursion system. He has the bounty entry in his journal as well as a surcharge on the bounty thanks to the Sansha.

Here are the lines in question:

Quote:
date="2011-09-30 21:45:00" refID="4927408366" refTypeID="85" ownerName1="CONCORD" ownerID1="1000125" ownerName2="Jargo Fat" ownerID2="904379550" argName1="Salah" argID1="30004146" amount="276592.00" balance="8567012.16" reason="16929:3,16930:2,16940:10,16946:3,16953:6,17593:1,23970:3,23979:7,23980:1," taxReceiverID="" taxAmount=""

date="2011-09-30 21:45:00" refID="4927408366" refTypeID="101" ownerName1="CONCORD" ownerID1="1000125" ownerName2="Jargo Fat" ownerID2="904379550" argName1="Salah" argID1="30004146" amount="-138296.00" balance="8428716.16" reason="16929:3,16930:2,16940:10,16946:3,16953:6,17593:1,23970:3,23979:7,23980:1," taxReceiverID="" taxAmount=""


I have a primary key of date, refID, charID/corpID, divisionID so this causes me problems. How are other people handling this? I could add refTypeID, but that doesn't feel right.
Dragonaire
Here there be Dragons
#2 - 2011-10-03 20:56:42 UTC
My understanding was each entry in the WalletJournal was suppose to get it's own refID since that how it worked in the past so you are probably seeing a bug in the API and should report it.

Finds camping stations from the inside much easier. Designer of Yapeal for the Eve API. Check out the Yapeal PHP API Library thread.
Captain Xero
3 Star Industries
#3 - 2011-10-03 21:19:20 UTC
That's what I thought, glad to hear you say that!

I know the refID has been recycled in the past, so I consider date as well. It's also possible to have the same refID for 2 different characters or for 2 different divisions in the same corp (2 sides of the same transaction).

This one doesn't seem to make sense though. I guess it's a levy on a transaction? Almost logical.
Dragonaire
Here there be Dragons
#4 - 2011-10-04 00:16:31 UTC
I'd say they forgot to increment the refID somehow myself. Since they changed to 64 bit IDs they stopped recycling them.

Finds camping stations from the inside much easier. Designer of Yapeal for the Eve API. Check out the Yapeal PHP API Library thread.
Hel O'Ween
Men On A Mission
#5 - 2011-10-04 11:00:13 UTC  |  Edited by: Hel O'Ween
Dragonaire wrote:
My understanding was each entry in the WalletJournal was suppose to get it's own refID since that how it worked in the past


You are mistaken than.

Each journal transaction gets its unique ID - on "both sides". For a buy order a (journal) transaction consists two entries: the buyer's part and the seller's part. Both share the same refID.

I first stumbled over this when someone bought from his own sell order and later on again if someone bought from or sold to a order of his own corporation. Both have (and always had, as far as I can tell) the same refID. They did however differ in the refTypeID.

EVEWalletAware - an offline wallet manager.
Captain Xero
3 Star Industries
#6 - 2011-10-04 11:54:51 UTC
Yeah that's my understanding. I use charID, corpID/DivisionID in the key along with refID for that reason.

What's different here is that I'm getting the same refID in the same journal for separate transactions of differing amounts. That doesn't seem right, I think that's what Dragonaire was getting at?
Matthew
BloodStar Technologies
#7 - 2011-10-04 12:01:38 UTC
I can't remember how off-hand, but I remember I found a "trading with yourself" case where even refTypeID was not a sufficient dis-ambiguator. The only way I could tell which side of the "Journal Transaction" was which was that the "amount" in one record was positive, and in the other it was negative. So I've actually got "amount" as part of the key now to handle that.
Lutz Major
Austriae Est Imperare Orbi Universo
#8 - 2011-10-04 13:40:40 UTC
It's not only buying from your own orders. It happens, when you make Player donations for a corp:

Quote:

row date="2010-11-14 19:50:00" refID="3496934333" refTypeID="10" ownerName1="Lutz Major" ownerID1="309020808" ownerName2="Austriae Est Imperare Orbi Universo" ownerID2="919606146" argName1="" argID1="0" amount="-2412739018.43" balance="300000000.00" reason="" taxReceiverID="" taxAmount="" /

row date="2010-11-14 19:50:00" refID="3496934333" refTypeID="10" ownerName1="Lutz Major" ownerID1="309020808" ownerName2="Austriae Est Imperare Orbi Universo" ownerID2="919606146" argName1="" argID1="0" amount="2412739018.43" balance="3349525163.42" reason="" taxReceiverID="" taxAmount="" /



I've also 26 other double entries since 2009: They are all either Player Trading (1), Player Donation (10), Corporation Account Withdrawal (37) and Contract Price (71).
They differ only by the amount (one negative, one positive - player tradings have amount=0!) and by the balance.
Kossaw
Body Count Inc.
Mercenary Coalition
#9 - 2011-10-04 14:04:04 UTC
Ouch, I think Lutz' example makes it pretty clear the refID is bugged.

While I can see the kind of twisted logic that related buy / sell orders etc have the same refID, the result is that you do in fact have the potential for completely duplicate records where both the "amount=0" and the balance is the same.

WTB : An image in my signature
Hel O'Ween
Men On A Mission
#10 - 2011-10-04 15:39:16 UTC
Lutz Major wrote:
It's not only buying from your own orders. It happens, when you make Player donations for a corp:
I've also 26 other double entries since 2009: They are all either Player Trading (1), Player Donation (10), Corporation Account Withdrawal (37) and Contract Price (71).
They differ only by the amount (one negative, one positive - player tradings have amount=0!) and by the balance.


Hehe, I never stumbled upon that one, because since EWA's invention I had my own flag CharOrCorp in all tables, which was set automatically depending on the type of API (personal API or corp API) the user queried.

EVEWalletAware - an offline wallet manager.
Dragonaire
Here there be Dragons
#11 - 2011-10-04 17:37:22 UTC  |  Edited by: Dragonaire
I add an ownerID and the accountKey to mine as well plus don't have personal and corp API data mixed together so haven't seen any issues there. With them, refID, and refTypeID, and possibly balance everything should end up unique.

Just on a lighter note I have to ask isn't buying and selling to yourself etc kind of like talking to yourself or worse since your even answering yourself which they say is a true sign you have problemsBig smile

Finds camping stations from the inside much easier. Designer of Yapeal for the Eve API. Check out the Yapeal PHP API Library thread.
Lutz Major
Austriae Est Imperare Orbi Universo
#12 - 2011-10-04 18:05:47 UTC
Dragonaire wrote:
I add an ownerID and the accountKey to mine as well plus don't have personal and corp API data mixed together so haven't seen any issues there. With them, refID, and refTypeID, and possibly balance everything should end up unique.

Just on a lighter note I have to ask isn't buying and selling to yourself etc kind of like talking to yourself or worse since your even answering yourself which they say is a true sign you have problemsBig smile


I apologize, if I haven't made myself clear: the above rows and the other 25 entries are/were from the same character from the same requests to the WalletJournal. I, like you, store a masterID and also a requestID (meta data for the actual request) to every entry.
When I query and group for the refID only and do a count(*) I have about 60 double and four triple entries.
Dragonaire
Here there be Dragons
#13 - 2011-10-04 18:17:41 UTC
Seems this is another case were CCP broke something that use to work so well P
I'm going to have to take a long hard look at both WalletJournal and WalletTransactions in the near future as it seems CCP has broken walking back through entries so going to have to start using forward walking I think and just go with my own unique ID and move away from the original upsert system I used with Yapeal P

Finds camping stations from the inside much easier. Designer of Yapeal for the Eve API. Check out the Yapeal PHP API Library thread.
Captain Xero
3 Star Industries
#14 - 2011-10-04 18:27:36 UTC
Thanks guys, came in with 1 problem, left with 3 :p

I can use a technical key for storing entries. However, the issue then becomes how to tell if you have the entry already in the database. If the refID, characterID, dateTime are all the same you're not able to tell entries apart. Using balance doesn't seem like a good solution because we've already seen a few cases where the transaction is 0 ISK, which would make the balance the same.
Hel O'Ween
Men On A Mission
#15 - 2011-10-04 20:33:40 UTC
Dragonaire wrote:

Just on a lighter note I have to ask isn't buying and selling to yourself etc kind of like talking to yourself or worse since your even answering yourself which they say is a true sign you have problemsBig smile


Well, it's not that this was my intention (and that personal/account thingie got reported by a user), but I forgot that I set up that sell order and was in need of a module for a fitting. I could have used one of those trader apps, like ... erhm ... EWA , though Oops

Captain Xero wrote:
Thanks guys, came in with 1 problem, left with 3 :p


You're welcome. Always at your service, Sire! Blink

EVEWalletAware - an offline wallet manager.