Cylon Programming Principle

Introducing the Cylon Programming Principle: "In well-designed software, there is only one god." (And his name is Singleton?)

Eclipse Forms vs. Context Menus

If you are using Eclipse's form toolkit infrastructure, you might run into an problem where you try to install a context menu but it does not appear. If you are using FormToolkit.adapt(Composite) to adapt a custom composite to a form, you must install your menu after adapting it. Otherwise, your menu will be replaced by the parent's menu. This may seem to be reasonable behaviour -- except when the parent widget has no menu at all.

XML Tricks in SQL Server 2005

Here are some stupid pet XML tricks in SQL Server 2005...

To XML-escape text stored in a column:

SELECT CAST('' AS XML).query('sql:column("v.v")')
FROM (SELECT '<>''"&' AS v) AS v

To XML-escape text stored in a variable:

DECLARE @myText AS NVARCHAR(MAX)
SELECT @myText = '<>''"&'
SELECT CAST('' AS XML).query('sql:variable("@myText")')

To extract individual nodes from XML:

SELECT result.node.query('.')
FROM (SELECT CAST('<x><a/><b/><c/></x>' AS XML) AS x) AS x
CROSS APPLY x.x.nodes('/x/*') AS result(node)

Use XML to perform concatenation aggregation:

;WITH
  strings AS (SELECT 'a' AS s UNION SELECT 'b' UNION SELECT 'c')
SELECT
  (SELECT s AS 'text()' FROM strings FOR XML PATH(''))

Generate nested XML, avoiding FOR XML EXPLICIT:

SELECT
  1 AS "@id"
, 2 AS "a/b/c"
, (SELECT v AS "e"
   FROM (SELECT 1 AS v UNION SELECT 2) AS v
   FOR XML PATH('d'), TYPE )
, 3 AS "text()"
, 4 AS "data()"
FOR XML PATH('element'), ROOT('root')

Use XML namespaces:

;WITH XMLNAMESPACES
( DEFAULT 'urn:default'
, 'urn:a' AS "a"
)
SELECT 1 AS 'a:y' FOR XML PATH('x')

Hibernate User Types vs. Field Access

In Hibernate (3.2), one can define persistence entity properties that have customized types. There is, however, a bug that arises if the property is mapped with an access type of field. In that circumstance, the following two problems occur if the entity is accessed through a proxy:

• a reference to the property through a getter method will not trigger initialization of the proxy
• even if the proxy has been initialized, a getter method will still return an uninitialized value instead of the calculated custom field value (in a debugger, one can see that the proxy is initialized and has a properly loaded target object with the correct custom value -- but the getter returns the uninitialized value just the same)

These problems disappear if the custom-valued property is defined with property access (i.e. getter/setter).

Regular, non-custom properties do not exhibit these problems. I do not know whether this problem has been fixed in later versions of Hibernate. I could find no mention of the problem on the 'net. But then again, Hibernate 3.2 is all but obsolete -- I'm just stuck with it right now.

The second problem may be partly a consequence of another proxy pitfall: proxy field values never change -- even after the proxy has been initialized. The field values will be whatever the no-argument constructor assigns to them (typically zeroes and nulls). You must access proxied properties through this or a getter/setter.

There is a consequence of uninitialized proxy fields that had never occurred to me, but which popped up repeatedly while I was Googling for the original custom-type problem. Uninitialized proxy fields will be particularly apparent in equals() methods (which are virtually impossible to get correct in a Hibernate context anyway, but that is a story for another day). It is extremely common to see code like this._field == that._field in equals() methods. If that is a proxy, this code will not work since the wrong field value will be obtained. Advance Hibernate Proxy Pitfalls on the Xebia blog is one of many examples of discussion on this topic.