JBossDeveloper

"ovidiu.feodorov@jboss.com" wrote:

Keeping information like "destination" in its own main table field will speed up queries, isn't it? Otherwise, you'll need to use a JOIN instead of a simple SELECT.

Stuffing non-generic information as message headers will impact performance. It's difficult to say how much, without proper measuring, though.

This is what migration utilities are for. We won't have to live forever with it, we will just have to go through the trouble of writing a migration tool. We need to do this while migrating from 1.0 to 1.2 anyway.

Personally, I don't believe in the "perfect generic design" that "fits every possible case". We need to have a plan for evolution, not perfection, which is unattainable.

"clebert.suconic@jboss.com" wrote:


It's even worse...

If you use composed fields... and if you need eventually to perform a JOIN...
you will need to do something like
WHERE SUBSTRING(COMPOSED_FIELD,1,5) = "DESTINATION"

or something like that...

If you have 100 systems... it's better to have 100 columns than a single column with 100 substrings to deal with. :-)

"ovidiu.feodorov@jboss.com" wrote:


Could you please jot down the schema, as you think it should be

Let me-reiterate.

The point of this task is to get the schema to a stable state so we don't have to writing migration scripts every time we do a release.

The columns I am considering removing are vestigial, they are not used in any joins. Also they more than likely negatively effect performance due to the extra unnecessary number of columns the database has to deal with.

If someone wants to find out the actual jms destination they can join the channel id to the channel mapper table.

If we're not going to remove them now, we will probably do so a few months down the line anyway, in which case we will have to write a migration script, and will have customers with a messy straggling database with some columns used, some columns not used. I.e. a support head ache. If everyone is using the same db schema then it makes a hell of a lot easier.

If we make changes to the schema as I suggest this means we can support pretty much any message type without changing the format. So we have stability, performance, future proofing, clarity and conciseness.

If someone really wants a normalised JMS specific database as Clebert would like, then they can create a JDBCPersistenceManager that does this.

Yes, this will be as slow as a tortoise on crutches, but it's possible.

IMO the default out of the box schema should be simple and performant and not contain redundant columns that seem to server no real purpose.

There is already a column that stores the headers called coreheaders.

I am just suggesting putting jmsdestination, jmstype and jmscorrelationid in there with the other headers.

I can see there is value in joining on jmsdestination for, for example reports, but this isn't lost, you can still get the jms destination in a query by joining channel id with channel mapper.

"clebert.suconic@jboss.com" wrote:


It's okay... as long we don't create a string parsing hell on the code.

Also bear in mind that JBoss MQ, does not store the jms headers in separate columns, so it's not as if people who are used to JBossMQ will be losing out:

JBosMQ:

 CREATE_MESSAGE_TABLE = CREATE TABLE JMS_MESSAGES ( MESSAGEID INTEGER NOT NULL, \
 DESTINATION VARCHAR(255) NOT NULL, TXID INTEGER, TXOP CHAR(1), \
 MESSAGEBLOB BLOB, PRIMARY KEY (MESSAGEID, DESTINATION) )

"clebert.suconic@jboss.com" wrote:

Well, we do. For people who want to migrate from 1.0 to 1.2 and have persistent messages in the database.

Shouldn't them consume their messages on 1.0 before migrating to 1.2?