Henning Westerholt wrote:
On Dienstag, 22. Mai 2007, you wrote:
during my work with the database schemas i've noticed and fixed some
issues with the current schema:

- addition of a version field to pdt table
Then the pdt module should also check the version number.

Hello Klaus,

ok, that make sense. I'll look into this next week.

- change uri: uri_user field length from 50 to 64 (standard user data
length)
Is this a global #define or is it hardcoded in every table definition?

Of course a #define. :-) All these values are in db/schema/entities.xml defined.

- change sip_trace: callid and :status from 254 to 255, and sip_trace:
[..]
- presentity: domain from 124 to 128 increased
There is also mismatch between column types, maybe you can take a look
at this too.
   Postgresql:
presentity.body is a "bytea"
xcap_xml.xcap   is a "text"
The presentity.body column type was changed to "bytea" because the presence module did not work when it was set to "text". When the column type is "text" you will get this following error 0

(14253) PRESENCE:agregate_xmls: ERROR while parsing xml body message

The details of the issue and my solution are documented in Bug # 1684821

This is already fixed in the new schema.

- xcap_xml: user from 66 to 64 decreased
- pua:watcher_uri and pres_user increased from 128 to 255 (std. URI
length)

In my opinion it's more resonable to have some standard length for
datatypes, what do you think about this changes?
sounds reasonable

At the moment the IDs for the tables are either signed or unsigned.
Should i change this to only one type?
I think unsigned sounds better for an ID, but AFAIK postgresql does not
support unsigned integer. The "serial" is some kind of unsigned integer.

Ok, good. Postgresql uses already "INTEGER(10) SERIAL NOT NULL" for the id fields.

Henning


_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel


Steve

_______________________________________________
Devel mailing list
Devel@openser.org
http://openser.org/cgi-bin/mailman/listinfo/devel

Reply via email to