in

ljusberg.se

Smöråkning

December 2004 - Posts

  • COM+ vs. .NET role-based security

    Being the first one to implement a .NET-based architecture at our department of Observer, I'm facing all sorts of issues that I didn't know and/or didn't care about a few weeks ago.. One such thing that I found today is that there are two, pretty much completely different, role-based security models that you can use whan developing a .NET application; COM+ role-based security or "standard" role-based security.

    Luckily, we already use COM+ role-based security for our old VB6 apps, so the choice for me was rather easy.. Anyway, if you're interested, I found this rather interesting article that summarizes the two different models, and suggests a way of combining them:
    Security: Unify the Role-Based Security Models for Enterprise and Application Domains with .NET -- MSDN Magazine, May 2002

    Posted Dec 20 2004, 03:39 PM by anders with no comments
    Filed under:
  • VSSEMS - a Utility for SourceSafe Administrators

    Just found this excellent VSS tool. Among other things, it can import users from a users.txt file into your Source Safe DB which was exactly what I was looking for!
  • PVR á la Anders

    You know, I've always wanted to build my own PVR (even long before I had even heard the expression), but it's not until now that I really feel that the time has come to actually do it!

    And why now, you say? Well, let me tell you.. Or actually, let me show you.

    Have a look at this gorgeous case (called Cubit 3) from Hoojum. Isn't it just the most beautiful thing you've ever seen? I mean, the Apple G4 Cube was pretty, but it isn't even close!

    Curious on the rest of the specs? Well, I'm not completely sure yet, because it all depends on what people say about the upcoming Via EPIA SP mainboard, but I sure hope that the fanless 800Mhz version will be enough. Add a good-sized SATA drive, 512Mb of RAM, a slot-in DVD and last but not least, a Hauppauge PVR 350, and I'll have a pretty nice setup, don't you agree?

    Posted Dec 07 2004, 04:22 PM by anders with no comments
    Filed under:
  • More Oracle XMLType

    So, in my last post, I told you about the Oracle XMLType and how to add XML data to tables that are based on XML Schemas. Now, storing data is not really that useful if you can't work with it, and this is where the XMLType really starts to get interesting.

    I think it's time we get our hands dirty with some practical examples.. Have you ever tried to make a nice hierarchical forum by using a relational database? You'll probably implement it with a "recursive" table, which is really nice from a logical viewpoint, something like this:

    ForumThread
    ThreadID - Integer (PK)
    Subject - String
    RootEntryID - Integer (FK to ForumEntry)

    ForumEntry
    EntryID - Integer
    Content - String
    UserID - Integer (FK to some User table)
    ParentEntryID - Integer (FK to ForumEntry)

    However, when you try to actually use it it quickly becomes more difficult. You end up with creating recursive loops that require loads of database lookups just to display the hierarchy. When I did this the last time, I actually gave up and decided that a one-level hierarchy would have to be enough.

    But hey, isn't XML pretty good at representing hierarchy? Let's try to do the same thing, but instead of having a ParentEntryID column on each Entry, we keep all this information in an XMLType column on the Thread!

    ForumThread
    ThreadID - Integer (PK)
    Subject - String
    Hierarchy - XMLType

    ForumEntry
    EntryID - Integer (PK)
    UserID - Integer (FK to some User table)
    Content - String

    The XML stored in "Hierarchy" could look something like:

    <Thread>
    <Entry ID="1">
    <Entry ID="2" />
    <Entry ID="3" />
    <Entry ID="4">
    <Entry ID="5" />
    <Entry ID="6" />
    </Entry>
    <Entry ID="7" />
    </Entry>
    </Thread>

    Note that this is rather simplified.. you probably want to add some more fields etc..

    Now, last time I promised to show you a little bit on how to query the stored XML using XPath expressions.. You do this by using one of two basic methods; "existsNode()" and "extractValue()".

    Let's say, for example, that you want to know which ThreadID that contains the Entry with an ID of 4. You do this with a query like this:

    SELECT t.ThreadID FROM THREAD t WHERE existsNode(t.Hierarchy, '//Entry[@ID=4]')

    Or, let's say that you want to know the EntryID of the root entry for all threads:

    SELECT extractValue(t.Hierarchy, '/Thread/Entry[1]/@ID') FROM THREAD t

    It's really as simple as that!

    If you are new to the concepts of XPath, why not have a look at the tutorial at W3Schools. It's all nice and free!

    Posted Dec 06 2004, 02:41 PM by anders with no comments
    Filed under: ,
  • Oracle XMLType

    As a Microsoft junkie, I haven't really used (or even bothered looking at) the Oracle database suite before. However, since it is the main database used by Observer, I've spent some time looking at the features of it - and I must say I'm pretty impressed.

    Did you know, for example, that Oracle has had support for storing XML data in a typed storage since version 9.2? This is something that is being added to SQL Server now in the Yukon release (SQL Server 2005) if I'm not completely mistaken. And it's pretty good stuff! Let me explain a little bit of how it works..

    First of all, you need to define an XML Schema (XSD) of the XML you want to store. You can do this with pretty much any XML tool, but I've come to prefer Altova XMLSpy (check out the free Home edition, it's really all you need in most cases..)

    Next, you register this schema in Oracle, and you give it a URL (I think it makes sense to use the URL of the schema itself). This URL is later on used when you add XML instances, but more on that later. When registering the schema, Oracle automagically creates a whole load of types, tables, arrays etc for storing instances of your XML documents without actually storing the XML string itself.

    After successfully registering a schema, you can add tables or columns that are based on the XMLType. Now, of course you can do this the hard way by issuing a couple of PL/SQL statements, but since I'm a complete n00b on Oracle, I prefer doing it the easy way via the Oracle Enterprise Manager GUI.. If you do it my way, you add a column, set the type to be "XMLType" and in the new tab that appears, you select your newly registered schema.

    Now, you are ready to add some XML to your table! The one thing you need to keep in mind is that the root element of the XML you're adding must refer to the XML Schema you've just registered. Let's say that you used a schema with no targetNamespace, and you registered it with the URL "http://ljusberg.com/xsd/test.xsd". This means that the XML you add must have the following attributes on the root element:

    <Root
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://ljusberg.com/xsd/test.xsd">
    ... rest of the xml document goes here ...
    </Root>
    

    You can then add this by a simple INSERT statement. Something like this should do the trick:

    INSERT INTO MY_TABLE (my_id, my_xml_column)
    VALUES (MY_SEQ.NEXTVAL, XMLType('<Root
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://ljusberg.com/xsd/test.xsd">
    ... rest of the xml document goes here ...
    </Root>'))

    Tada! Now you've added some XML to your table, pretty easy, isn't it? But this is when you can start doing some really cool stuff, such as selecting rows from your table by an XPath expression! But that will have to wait until my next post.

    If you want to know more about the inner workings of structured storage of an XMLType, check out this article from the Oracle documentation!

    Posted Dec 03 2004, 04:17 PM by anders with no comments
    Filed under: ,
  • Code conventions

    During the years I've seen a lot of different code convention documents, and they've all been huge and inaccessible. No-one ever read them through, and even if you did you couldn't possibly keep all of it in mind all the time.

    Anyway, since there was no such document here at Observer when I started, one of the tasks I was given was to set one up. I've just started working on it, and even though I'm mostly just referencing other things, such as the Microsoft naming guidlines, the document is already growing out of proportion..

    Something I still can't really decide on is how to write private field members that relate to public properties. I've seen two ways of doing it:

    private string _myProperty;
    public string MyProperty {
    get { return _myProperty; }
    }
    

    or

    private string myProperty;
    public string MyProperty {
    get { return myProperty; }
    }
    

    Sometimes I kind of like the underscore prefix way. Mostly because it makes it a little bit easier in the constructor since you can put:

    public MyClass(string myProperty)
    {
    _myProperty = myProperty;
    }
    

    instead of having to use the "this" pointer:

    public MyClass(string myProperty)
    {
    this.myProperty = myProperty;
    }
    

    However, I think it looks a bit crappy, don't you? Underscores really aren't the nicest characters around, and I thought we were moving away from having weird prefixes on our variables..?

    There are quite a few different discussions out there on this topic..
    Some agree with me, some don't

  • Mandatory test posting

    OK, this is my first, mandatory, test posting..

    I don't really have the time to introduce myself properly, so this will be a short post..

    My name is Anders Ljusberg, and I have recently started to work as a System Architect at Observer Group in Sweden. I'm most certainly not what you'd call "senior", but I've been in the business for about 6 years.

    Now, this blog will be focused on .NET development and architecture, since that is what I do all day (and dream about all night).

Powered by Community Server (Non-Commercial Edition), by Telligent Systems