Re: dlr_sdb bug

Hi Alexander.

On 17/09/03, Alexander Malysh ([email protected]) wrote:

> On Wednesday 17 September 2003 04:40, Rory Campbell-Lange wrote:
> > On 17/09/03, Andreas Fink ([email protected]) wrote:
> > > On Mittwoch, September 17, 2003, at 02:24  Uhr, Rory Campbell-Lange
> > > > Hi. I've been playing around using sdb for my dlr storage. I've got
> > > > it working nicely for Postgresql. However I had to do some muddling
> > > > around with the code (I've never worked with C before) after noting
> > > > some oddities in the database calls.
> > > >
> > > > UPDATE and DELETE don't take "Limit" clauses, certainly not for
> > > > Postgres.

> > > You can remove the LIMIT clauses, they are safety checks only to only
> > > modify one record if for some reasons there are two found.
> > > This should only happen if you send more than one message per second to
> > > the same destination over the same SMSC and get the same timestamp.
> >
> > Hi Andreas. My point is that the LIMIT clauses are not optional for
> > Postgres. You simply can't have them.

> that was a reason why I added sdb_get_limit_str(), so if db support another 
> limit clause (as oracle ROWNUM) then you can just add it there... Using 
> libsdb is anyway a bad idea, because libsdb doesn't support persistent db 
> connections. And from my experience, I know that opening a db connection take 
> more time as sql statement itself. 

Yes, of course you are right. We need persistant db connections.

> > Is there a way we could do this update on a unique id rather than the
> > timestamp (i.e. Kannel uses a value from the db rather than provide the
> > key?). For large dbs this could be optimised to provide very quick
> > performaance.
> 
> Heh, in order to find this unique key you must make select statement anyway. 
> Later if you have found a appropriate row, yes we should do it. But if you 
> speek about performance, then first what we should do (imo): get rid of 
> libsdb support and add native db support for db's we want...
> 
> Btw. I'm working on the patch that will get more dlr performance, so
> pls wait a bit:)

I'd very much like to help to provide postgresql support, but I don't
know any C! Maybe I'll have to read that Kernighan and Ritchie book on
my bookshelf some time!

Another issue is that, for us, having a DLR url is not needed if we can
store delivery reports in a db.

We have

        db -> send unset -> kannel -> dlr back to db

In a way we would like to just send a DLR parameter to kannel like
db.rowid and then kannel's db (postgres!) subsystem does an update of
db.rowid.

Lets just clarify that further, for a best-case scenario!

        kannel polls db for unsent -> sends unsent -> updates db with dlr

This doesn't use http calls at all.

Cheers!
Rory
-- 
Rory Campbell-Lange 
<[email protected]>
<www.campbell-lange.net>