-- ... stuff before
dynamic_select_cols := 'tbl1.foo, tbl1.bar, null AS theAlias1, null AS theAlias2, tbl2.foo2';
-- ... stuff after combining the dynamic queries
EXECUTE my_dynamic_query;

In my case the result of the query will be inserted in a temporary table in memory. The destination column for theAlias1 is of type INTEGER. When executing the query PostgreSQL gives me an error:

column "theAlias1" is of type integer but expression is of type text

So there is something wrong when the query is parsed, evaluated and executed.

Solving this was easy with the use of NULLIF. Zero equals zero so NULL is returned. Just as expected.

-- ... stuff before
dynamic_select_cols := 'tbl1.foo, tbl1.bar, NULLIF(0, 0) AS theAlias1, NULLIF(0, 0) AS theAlias2, tbl2.foo2';
-- ... stuff after combining the dynamic queries
EXECUTE my_dynamic_query;

You could of course comment in and out (via ctrl + k, ctrl + c / ctrl + k, ctrl + u) the SPSchedule used by the timer-job during debug-mode. But this is error-prone.

When using a C# preprocessor directive you cannot forget to switch back to the “production schedule” as this is done automatically (and even with syntax-highlighting depending on the active configuration!) when selecting the “release build”.


#if (DEBUG)
var schedule = new SPMinuteSchedule();
schedule.BeginSecond = 1;
schedule.EndSecond = 59;
schedule.Interval = 5;
#else
var schedule = new SPDailySchedule();
schedule.BeginHour = 7;
schedule.EndHour = 7;
schedule.BeginMinute = 1;
schedule.EndMinute = 59;
#endif

This code tells the compiler to use the SPMinuteSchedule when compiling the “debug build” and to use the SPDailySchedule when compiling in “release build”. All automatically!

From static …

Symfony allows the configuration of the mailer in its factories.yml. There smtp-settings can be definied. But in this case this is impossible as every client has different smtp-settings (every client can use its own smtp-settings to handle mailings).

As I did not want to create an instance of the Swift_Mailer (and Swift_SmtpTransport) myself I decided to create my own mailer-class which is derived from the symfony one. So I get the full benefits of logging.

… to dynamic

class myDynamicMailer extends sfMailer
{
  public function __construct(sfEventDispatcher $dispatcher, $options)
  {
    // Load client based configuration
    $cfg = EmailConfiguration::getCurrent();
 
    if(!$cfg->isSmtpConfigured())
    {
      $options["class"] = "Swift_MailTransport";
    }
    else
    {
      // Update settings for the current client
      $options["transport"]["param"]["host"]      = $cfg->getHostname();
      $options["transport"]["param"]["port"]      = $cfg->getPort();
      $options["transport"]["param"]["username"]  = $cfg->getUsername();
      $options["transport"]["param"]["password"]  = $cfg->getDecryptedPassword();
    }
 
    parent::__construct($dispatcher, $options);
  }
}

Simply update factories.yml with the new class and the dynamic configuration is applied.

all:
  mailer:
    class: myDynamicMailer
    # Rest follows here

No improvements since the Beta! Not all lists support the new AJAX-Dialogs. The page-management (for multi-paged workspaces) is still the same as in 2007. Even some old (SP 2007) graphics appear. The handling is that awful, too. So the whole “area” of meeting-workspaces leaves with an “nothing happened here”-impression.

Additionally the meeting-workspace ribbon in Outlook 2010 is gone! You can get it back, but its not that preset as in 2007. This was a really nice feature in 2007. Outlook combined with meeting workspaces.

When taking all this together I’m really disappointed.
It comes to my mind that this whole “meeting-workspace-flow” will soon be removed from SharePoint/Outlook – No real improvements in SharePoint 2010 (haven’t tested building site-definitions from meeting-workspaces but I guess its still as hard as in 2007), ribbon in Office 2010 is gone per default and somewhat hidden.

Im Kern wird die schnellere Ausfuehrung der Query dadurch realisiert, dass mittels der WITH-Klausel die Ergebnismenge der Subquery vorab materialisiert, mit einem Namen versehen und schliesslich in der Hauptquery abgegriffen wird.
Hier lohnt sich auch ein Vergleich und Gebrauch von "global temporary tables", die in Ihrer Funktions- und Wirkungsweise durchaus ähnlich sind:
Durch Entkopplung geeigneter Subqueries, die urspruenglich als Bestandteile einer komplexen Abfrage fungierten, wird dieses SQL-Statement vereinfacht.

WITH   SQ1 AS (SELECT...FROM...WHERE...),
       SQ2 AS (SELECT...FROM...WHERE...)
SELECT...
  FROM Q1, SQ1, SQ2 WHERE…

Interessanter Nebeneffekt:

Durch die Verwendung der WITH-Klausel wird anscheinend in einer Systemumgebung mit voreingestelltem CURSOR_SHARING=FORCE offensichtlich fuer die Query-Ausfuehrung diese systemweit gueltige Einstellung auf CURSOR_SHARING=EXACT zurueckgenommen (vergleichbar dem Einsatz des Hint /*+ cursor_sharing_exact */).

Zeigen die QEPs vorher noch eine allgemeine Ersetzung von Konstanten durch Parameter, so weisen die QEPs nachher die direkte Verwendung der Konstanten auf.

Somit orientiert sich der Optimizer auch grundsaetzlich an anderen Zugriffsstrategien.

Was in einer Umgebung mit problematischem Parseverhalten per Bindvariablen-Peeking einen "flüssigen" Anwendungsbetrieb ermöglichen kann, wird im Einzelfall einer komplexen Query unter Verwendung von Attributen mit stark ungleicher Werteverteilung zu relativ kostenintensiven QEPs führen.

Es empfiehlt sich dann für alle entsprechenden Konstanten/Parameter einen separaten und speziellen QEP zu erzwingen.

Vorraussetzung:

SQL-99 Standard bzw. Oracle9i Release 2

Links:

SQLStandards.html

to be continued….

SELECT MIN(id)
     , MAX(id)
  FROM big_table

Bei diesem SELECT kommt zwar das richtige Ergebnis, dennoch kann die Antwortzeit sehr lange dauern. Der Grund liegt in einem FAST FULL INDEX SCAN.

Besser ist folgendes:

SELECT MIN(id) min_value
  FROM big_table
 UNION ALL
SELECT MAX(id) max_value
  FROM big_table

oder

SELECT (SELECT MIN(id) from big_table) min_value
      ,(SELECT MAX(id) from big_table) max_value
  FROM dual

Bei beiden alternativen wird ein FULL INDEX SCAN durchgeführt und liefert das Ergebnis (fast) sofort zurück.
Den Umweg sollte man bei großen Tabellen und wo es auf Geschwindigkeit ankommt wählen.

SELECT
     , b.username blocking_username
     , b.osuser blocking_osuser
     , b.machine blocking_machine
     , b.program blocking_program
     , w.sid waiting_sid
     , w.username waiting_username
     , w.osuser waiting_osuser
     , w.machine waiting_machine
     , w.seconds_in_wait
  FROM v$SESSION w
     , v$SESSION b
 WHERE w.blocking_session is not NULL
   AND b.sid = w.blocking_session
 ORDER BY w.sid

Das Statement kann jederzeit um weitere Spalten erweitert werden.

Folgendes Beispiel soll die einfache Lösung aufzeigen:

SELECT a.id
     , a.parent_id
     , a.label
     , a.sort
  FROM menu_tree a
 ORDER BY 2 nulls first,1

(Abbildung 1: Unsortierte Basistabelle)

SELECT LEVEL
     , rpad(' ',LEVEL) || label
  FROM menu_tree a
 START WITH a.parent_id IS NULL
       CONNECT BY PRIOR a.id= a.parent_id
 ORDER siblings BY sort

(Abbildung 2: Sortiertes Ergebnis)

Debian lenny stable packages are bundled with Postgres 8.3.x but thanks to Debian Backports the newer Postgres version is available for lenny.

Simply do it

Add the backports-sources (/etc/apt/sources.list) and update (apt-get update)

deb http://www.backports.org/debian lenny-backports main contrib non-free

Install postgres

apt-get -t lenny-backports install postgresql-8.4

Object model?!

When looking into the SPFieldLookup-class you find the properties LookupField, LookupList and LookupWebId. LookupWebId and LookupField can easily be set via the object model. The documentation says that LookupList is read and writeable which is not true. Setting LookupList throws an exception stating out “Cannot change the lookup list of the lookup field.”.

SchemaXml and Regex to the rescue

The SchemaXml-property of a SPField can be used to manipulate the LookupList. One stumbling block is that you do not know the Guid of the LookupList currently stored in the schema. Even if you define a Guid inside your xml-field-definition SharePoint puts in an other Guid. Here a simple regular expression comes to help.

The code for connecting a site-column with a list somewhere in some web:

// Declarations (myWeb is the context given by a feature receiver scoped "web")
var rx = new Regex("List=\"([^\"]*)\"", RegexOptions.IgnoreCase | RegexOptions.ECMAScript);
var root = myWeb.Site.RootWeb;
 
// myListInstance is an instance of a SPList existing somewhere
var lookupField = (SPFieldLookup)root.Fields["MyLookupField"];
var xml = lookupField.SchemaXml;
xml = rx.Replace(xml, String.Format("List=\"{0}\"", myListInstance.ID.ToString("B")));
lookupField.SchemaXml = xml;
// Do not call update here!
// Quote from MSDN "Do not call the Update method when using the SchemaXml  property to modify a field."
 
// Fetch the field again and apply the web-id
var lookupFieldReFetch = (SPFieldLookup)root.Fields["MyLookupField"];
lookupFieldReFetch.LookupWebId = myWeb.ID;
lookupFieldReFetch.LookupField = "Title";
lookupFieldReFetch.Update(true);

This problem still persists in the beta of SharePoint 2010. I hope this will get fixed in the RTM. Creating a lookup-field-connection is far more easy by the way …