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>
