Nisan Bloch wrote: > At 10:01 PM 7/10/02 +0200, Andreas Fink wrote: > >>> Hi All >>> >>> A small patch to the dlr code. >>> In a situation of highload, we get duplicate ts columns in the >>> dlr.dlr table for a particular smsc. The Mysql dlr_find code, did >>> not take the destination into account in its query. Patch makes the >>> SQL in dlr_find search on smsc, ts, destination rather than just >>> smsc,ts >>> >>> Nisan >> >> >> >> this wont work if the submitted number doesnt match the number the >> SMSC is giving back. Example: I send to +4179245733 which is my phone >> number in international format. The EMI driver will make 004179245733 >> out of it but the report will show 079245733 as the reported number >> because that's the national format. >> >> I was thinking of changing that and storing the timestamp as given >> back by the EMI ACK which would always match but then I have to >> update the record in memory/in database so I have to keep track the >> record number with the submitted sequence number. Not that easy as it >> sounded. > > > > ..eek.. didnt realise that with EMI.. With SMPP it isnt a problem, as > one has unique message ids, our modified http driver we gen our own > unique ids.. Do you think a closest right most match on the > destination would work, say 80% of the chars from the right match, > along with the ts and smsc_id?
Not a good idea, IMHO - you have no way to know how the destination number will be transofrmed (and I've seen some crooked ones). also - other drivers will behave differently from the two discussed here, and you have to take those into account too. -- Oded Arbel m-Wise mobile solutions
