On Friday 08 February 2008, Bogdan-Andrei Iancu wrote:
I'm really interested in focusing on things that really drawback openser
(as throughput) - and I do not refer at the non-sense lab tests (TM
performances :P) which more or less have 0 relevance in real life
scenarios.
So, as a first
Hi Victor,
Yes, I know your patch and I plan to use it as start point (patch id
1717848).I will port it to 1.4 and then add the DB API support and
extend usrloc/auth_db to make use of it.
Thanks and regards,
Bogdan
Victor Gamov wrote:
Hi Bogdan!
Sometimes ago I make patch for 1.2.0 which
Hi Bogdan!
Sometimes ago I make patch for 1.2.0 which introduce prepared statements
into mysql module. This patch was removed later because it incompatible
with current versions of OpenSER but I still have in mind to reproduce
this patch for CURRENT when DB API will be stable.
So if you plan
Hi Henning,
Indeed, it will be interesting to run the such tests, but some major
advantages we have with the current mem manager:
1) in private memory, we have no locking. Malloc from glibc does all
the time lock in order to be thread safe
2) debugging possibilities - I know there are
Hi Henning,
I'm really interested in focusing on things that really drawback openser
(as throughput) - and I do not refer at the non-sense lab tests (TM
performances :P) which more or less have 0 relevance in real life scenarios.
So, as a first plan, I wan to do some work on the DB part : I
Hi Henning,
Henning Westerholt wrote:
On Friday 08 February 2008, Bogdan-Andrei Iancu wrote:
I'm really interested in focusing on things that really drawback openser
(as throughput) - and I do not refer at the non-sense lab tests (TM
performances :P) which more or less have 0 relevance in
On Tuesday 05 February 2008, Daniel-Constantin Mierla wrote:
[..]
postgres, db_berkeley allocate new memory and copy all string values from
the database to the internal representation. Modules that uses this
driver don't need to copy there values, even after the freeing of the
result
Hi Henning,
It is not a rush at all - I just need to have an estimation to do my own
plans :). I agree that such changes takes time, and to be honest I
wasn't expecting such a short timeframe from you ;). I though it may
take some time (weeks) .
Thanks and regards,
Bogdan
Henning Westerholt
On Tuesday 05 February 2008, Bogdan-Andrei Iancu wrote:
For the VAL_NAMES-s exists the same issue, i'll evaluate if it make
sense to introduce a flag for them too.
well...is it needed any altering of the column names? so far I think all
are static (as returned by driver)
No, i don't think
Hi,
i've a question about the 'correct' way to do the memory management for
results in the database modules.
At the moment there existing two different styles:
mysql, unixodbc don't allocate new memory and just assign the string pointer
of the result set to the internal OpenSER
On Tuesday 05 February 2008, Daniel-Constantin Mierla wrote:
[..]
At the moment there existing two different styles:
mysql, unixodbc don't allocate new memory and just assign the string
pointer of the result set to the internal OpenSER representation. The
modules that needs to use this
Hi Henning,
I agree with you. I see here two arguments for this:
1) if mysql is not duplicating the date returned from driver, it
means all the modules using DB are already safe from this point of view
- they do their one copy and they do not count on the persistence of
data returned from
On 02/05/08 18:38, Henning Westerholt wrote:
On Tuesday 05 February 2008, Daniel-Constantin Mierla wrote:
[..]
At the moment there existing two different styles:
mysql, unixodbc don't allocate new memory and just assign the string
pointer of the result set to the internal OpenSER
On Tuesday 05 February 2008, Bogdan-Andrei Iancu wrote:
Hi Henning,
I agree with you. I see here two arguments for this:
1) if mysql is not duplicating the date returned from driver, it
means all the modules using DB are already safe from this point of view
- they do their one copy and
Hi Henning,
Henning Westerholt wrote:
On Tuesday 05 February 2008, Bogdan-Andrei Iancu wrote:
Hi Henning,
I agree with you. I see here two arguments for this:
1) if mysql is not duplicating the date returned from driver, it
means all the modules using DB are already safe from this
Henning Westerholt writes:
As we have many more modules than database connectors in the code, i
think it would make more sense to change the postgres and db_berkeley
module to match the behaviour of the mysql module.
Any comments?
i'm in favor of your suggestion. in case module does
16 matches
Mail list logo
