thinking-out-loud

Clemens on Transactional Queues

Clemens Vasters has a nice addition to his series on fault tolerant/reliable messaging. I especially liked the following lines of code that keep the begin/end peek in the same method:

IAsyncResult asynchResult = sourceQueue.BeginPeek(TimeSpan.FromSeconds( peekTimeout),null,null);
int firedWaitHandle = WaitHandle.WaitAny(new WaitHandle[]{asynchResult.AsyncWaitHandle, pauseInterrupt, stopInterrupt});
if ( firedWaitHandle == 0 )
{
  sourceQueue.EndPeek(asynchResult);

Interesting. Remarkably like a straight-up peek, but allowing for the stop and pause interrupts. The rest of the related code puts it into context, but it looks like fun stuff.

Testing VB6 with NUnit

We at Improving are huge fans of test-driven development (TDD).  I just started a short project for a client who requires the development (for very valid reasons) to be done in VB6.  I did a little research around TDD in VB6 and found vbUnit as well as some other tools.  However, months ago I'd heard about the rare and mysterious practice of unit testing VB6 code from NUnit.  Only, I couldn't find a single reference to it with Google.  So, here's what I learned from one of my wife's coworkers....

1. Create your VB6 code in an ActiveX DLL project (e.g. Project).  Add and develop classes as normal in this project.

2. Use menu item File|Make DLL to copile the DLL (e.g. Project.dll) and automatically register it for use.

3. In Microsoft Visual Studio .Net (or 2003), create a DLL solution and add references to the .Net assembly NUnit.Framework and the COM library produced by VB6 (e.g. Project).  VS.Net auto-gens a COM wrapper for you (e.g. Interop.Project.dll) in the bin directory.

4. Write .Net test cases to invoke member functions of classes in Project. You can make a using Project; statement if desired.  Build your DLL as normal.

5. Execute tests by FIRST running the ActiveX DLL from the VB6 environment.  This puts VB6 in debug mode.  Set a breakpoint somewhere to prove that it's working.  SECOND: launch NUnit, open your .Net assembly, and run some tests. 

NOTE: If you don't run the VB DLL first, NUnit will report a System.Runtime.InteropServices.COMException. 

Of course, once you're up and running, you'll want to change the order of these steps so you're actually writing your tests first. ;)

I hope to have NO other words of wisdom about hard to find answers to VB6 development questions from this project.  But, it is worth mentioning that www.connectionstrings.com had the answer I needed for connecting to a password-protected database with ADO.

Service Orientation, Law of Demeter

In my previous post, I made statements about scoping [autonomous] services. After thinking about the statement more, I realized that it reminded me of the spirit of the law of demeter. The law of demeter guides message passing in OO. It basically states that an object should only send messages to:

1. Itself
2. Its attributes
3. Parameters passed to it in the current method context
4. Objects contained in a collection it holds
5. Objects it creates itself

The spirit of demeter is that you, as an object, should minimize the number of assumptions you make about the implementation of the objects you reference and message. The same idea is true of services. If you are expected to depend on them, then the side effects must be explicit in the contract. Unfortunately, or maybe not so unfortunately if you actually want to get something done as opposed to waiting around for the spec lords to define a solution, the way that you define these assumptions currently is prose, ala WS-Transfer.

Schneider on the Four Tenets

I have read and re-read and re-re-read Jeff Schneider's post on Microsoft's Ron Jacob's webcast on Service Oriented Architecture. [whew]. While I tend to agree that only having four tenets at first glance sounds a little suspect, REST, the description of the architecture underlying the web, is composed of six constraints (which, if you squint your eyes, are tenets):

1. Client-Server
2. Stateless
3. Cache
4. Uniform Interface
5. Layered System
6. Code-on-demand

But then Jeff goes through the tenets one by one, challenging their meaning and offering an alternative tenet, and this is where the [re-]re-reading comes in. Let's dissect each in turn. Jeff says:

Boundaries are explicit - yep, hard to argue. But what does this actually say? How about this instead: "All exchanges of data, metadata, logic or other binary asset MUST BE exchanged through a contract. Runtime changes to code dependencies are NOT allowed."

Uh. No. That isn't it. Thanks for playing, though. Go back and read the source. "Boundaries are explicit" is about the fact that you can't see what kind of underpants I am wearing. If you want to know, you have to ask nicely by sending me a message. The contract stuff is in that other tenet. I have absolutely no idea what "Runtime changes to code dependencies are NOT allowed" has to do with explicitness of boundaries. In my estimation, nothing. I can think of a number of ways that runtime code dependencies could change in the context of a service oriented system, and everything would be just fine.

Services are autonomous - Most people know that I firmly believe that "services are not autonomous", they are synergistic. Services work together in a 'service ecosystem'. Services will influence each others metadata. In no way are services autonomous.

I don't agree. I believe that services *should* be autonomous, that their implementation dependency on other services is an implementation detail (because boundaries are explicit), and part of the responsibility of an autonomous service is to gracefully degrade service when its dependencies have availability or other issues. I do *not* go as far as Clemens Vasters does in talking about services waking up and touching, er, I mean, invoking themselves. While I do think that agent-based computing has its place, and I do buy into the notion he sells that services/message passing are a great way for agents to communicate, I don't buy into the notion that services are agents. I think it is important to make a distinction between services and agents, and that level of autonomy and self-directedness is one of the key distinctions I would try to make.

Interestingly, I think Jeff provides some much needed guidance on what would help scope an autonomous service in a different post on Design by Contract vs. Contract First, specifically, the bits about pre- and post-conditions, which are sorely missing from the WS-MESS.

My take: A service should be scoped to the level of assumed impact. If I can send a message to an endpoint and then safely assume something about the result of another message send, then those two message sends are coupled and most definitely not autonomous *without each other* and probably should correspondingly live together, i.e. be operations on the same service.

Consider the following: If I ask Fedex to send a package to my parents overnight and they agree, then I could verify the results one of two ways: call my parents, or check with Fedex. However, Fedex does nothing to guarantee that my parents will respond honestly. That isn't in the contract. They will, however, know whether or not they delivered it on time, what time they delivered it, whether or not someone was there to receive it, and if so, what the signature read. This is the essence of autonomy to me. Verifying package delivery isn't my parent's business, it's Fedex's business.

Jeff's next comment also seems to miss the mark for me:

Services share schema and contract, not class - I believe the point is that you want to share data using self describing, self validating, extensible schema systems that are ubiquitously deployed. That's cool - use an abstract typing system.

I think that this tenet is explicitly included for all of the rpc/distributed object guys, and I think that it can be loosely translated "Don't share dlls, don't share jars. It will hurt." Again I refer back to this great exchange. Network apis, *not* library apis.

I agree that it is impossible to completely avoid CRUD in many cases, but I have seen systems where every entity had a service crud interface, and that *is* a service smell/anti-pattern. The point is that the service interfaces should be coarser-grained and business-oriented. The difficulty is that one man's operation is another man's entity (think "Order" vs. "Order"). REST normalizes this by forcing you to view everything as a resource, i.e. a noun, and then restricting what you can do with that noun to a small set of verbs + post, the latter of which, loosely translated, becomes "do whatever the hell you want [in the scope of this resource]." Services looks at everthing as a operation, i.e. a verb.

I do like his questions about open-ended interfaces.

FWIW, I know that Jeff is a bright guy. Its apparent from his blog. And I like the fact that he's doing things like ServiceOriented and ProcessDriven, and OpenStorm is at a minimum a cool brand name, and it appears to be a lot more, though I haven't used it. And I trust he can explain what he means in a way that someone as simple as me can understand. I hope he does, because I don't get it.

Refactoring, Dottext, Remove Typesafe Collection

I recently mentioned that Improving is planning an upcoming product release. The product is an open source toolkit for object relational mapping and database related code generation, Or. We view it as a competitor to NHibernate. Although it probably won't be as feature-rich near-term, it will definitely hit a useful sweet spot, and provide Improving a platform to discuss a number of design decisions, corners of the .NET framework, and, of course, object relational mapping techniques.

As part of the release, we wanted to have sample applications that demonstrate its use (in lieu of quality documentation that should follow.) We decided tactically that rather than create a canned application, it would make more sense to start with some existing, open-source sample applications, port them to use the framework, and then do a before/after comparison to see what and whether the changes improved the application (gratuitous marketing: Improving. Its what we do.) For the first release, we thought we would start with Microsoft's own sample TimeTracker application from ASP.NET and Dottext, the popular, open source blog server application. Todd is hacking up the TimeTracker, and I was taking on the .Text code base.

Now.

Before I get into this, I think the following disclaimer needs to be shared. Design is full of trade-offs, and many designs are [thank you, Mr. Weinberg] how they are because they got that way. It is probably reasonable to assume that, with the exception of a few choice pieces of code, there is always a way to improve on an existing design. That is one of the core tenets of our brand, Improving -- there is *always* room for Improving. I respect and applaud Microsoft for releasing to open-source the sample Time Tracker app to provide a concrete example of how to use ASP.NET. Even more than that, I respect and applaud Scott Watermasysk for giving his code to the community, even though he reserved the right to take it back and, under new employment, appears to have done so. We are giving our code to the community as well with the release of Or. We fully expect someone not so close to our code could look at it and find tons of opportunities for Improving the design, and we welcome it. If you have great ideas that you want to share, email or at improvingtech.com and ask to become a committer. We are going to be very picky about who gets on the committer list, so we expect you to demonstrate yourself with real live code.

Now.

Back to the application I have been focusing on - .Text. .Text is a blogging platform that supports a variety of syndication formats and multiple blogs. It is backed by a Sql Server database and has a very consistent design, which makes it fairly easy to understand and modify. All of these things, at first glance, make it appear to be a good candidate for the port to Or. As I dug deeper, however, I found a number of twists that made the port challenging, and I was distracted by a number of coding techniques that I don't typically practice. For example, I almost never create typesafe collections. I want to be able to support typesafe collections in Or, but I haven't really taken the time to test things out. I thought I would dig a little deeper in .Text to understand how it was using them, and the result of that investigation is this post.

Typesafe collections provide a [go figure] typesafe data structure for managing multiple instances of the same type of object. I really didn't see typesafe collections much before I developed with Microsoft technologies. To me, typesafe collections have the potential to provide a number of benefits. First, you can restrict the type of objects that are passed into a collection. This ensures that the types that you get out are also of the same type. Second, if you go further in your implementation of typesafe collections than the average [.NET] implementation, you can eek a small bit of performance out of your collection by backing it with a typesafe array, allowing you to avoid the cost of casting to and from your target contained type, which adds at least an isinst IL, which, relative to some other IL ops, is fairly expensive. If the majority of the time in your application is spent iterating over collections of objects, this could actually have a pretty significant impact on the the responsiveness. This has never [ever... EVER] been the bottleneck for me, but your mileage may vary. I can imagine plenty of cpu intensive cases that might yield such results, and I know close personal friends who have had to deal with similar problems in Java many moons ago, but we all know that *that* was because it was implemented in Java, right guys? Come on? Your with me, aren't you? [Of course not].

For what it's worth, my experience has shown that the real bottleneck is almost always i/o, and it is typically disk first, network second, unless you're doing something really stupid, er, I mean, naive, er, I mean innocent, like accessing properties on distributed objects, which everyone should know by now is a bad idea. There are some who would say distributed objects at all are a bad idea. I definitely prefer [text-based] message passing ala services or REST. Back to our story.

As I dug deeper on the typesafe collections, I noticed a number of things. First, the code that accesses the collections in .Text almost always looks like the following:

KeyWordCollection kwc = GetKeyWords();
if(kwc != null && kwc.Count > 0)
{
  KeyWord kw = null;
  for(int i =0; i.Count;i++)
  {
    kw = kwc[i];
    entry.Body = 
      ReplaceFormat(
        entry.Body,
        kw.Word,
        kw.GetFormat,
        kw.ReplaceFirstTimeOnly,
        kw.CaseSensitive);
  }
}

Without actually being responsible for designing the code, I can only presume that the code is written this way for performance reasons. First, the null check is paranoid-but-reasonable defensive measure. Second, the Count method from CollectionBase (which ends up delegating to an internal ArrayList, for what it is worth) is pretty darn cheap, as method calls go. Compare that with this slightly cleaner syntax sugar coated version that assumes that the GetKeywords() method will at least return an empty collection (which it does):

foreach( Keyword kw in GetKeyWords() )
{
  entry.Body = 
    ReplaceFormat(
      entry.Body,
      kw.Word,
      kw.GetFormat,
      kw.ReplaceFirstTimeOnly,
      kw.CaseSensitive);
}

This cleaner version hides the fact that under the covers, an Enumerator object is created, which is certainly more expensive than a null check and a Count check. Both implementations hide the fact that the reference is downcast, e.g. there is an isinst call [and its friends], with the typesafe collection having its downcast occuring in the indexer. I could just as easily do the same checks before the foreach version to gain the modicum of performance in the null case. Once again, I feel compelled to state that none of this has ever been material to an application I have written, but if you think it may be, PAYF. Again, if the typesafe implementation is backed by a typesafe array, a little more performance can be had. Given that, it would appear that the only benefit left to having a typesafe collection would be so that we could ensure that we are only allowing particular types to enter the collection. So, we get to this point and we have to ask ourselves, is the hundred or so lines of code necessary to build a typesafe collection in the manner that it is done in .Text worth the effort to gain the security of ensuring that we only add types we expect to add? For me, the answer is "No." This is largely due to the fact that I trust myself to only add in types that are homogeneous at some level in a hierarchy below object. I rarely have a situation where I have lots of different code adding objects to the same collection. If I do, the collection is usually an instance variable on another class, and I can protect the collection by implementing a mutator for the collection along the lines of:

public class Company
{
  public void Add(Employee e)
  {
    employees.Add(e);
  }
  private IList employees = new ArrayList();
}

I went through and deleted all of the typesafe collections and modified the code that accessed them to use foreach statements, and the code looked to me to be considerably cleaner and the number of classes and files that needed to be maintained were reduced. I *did* have to add back in a PagedList implementation and an ImageCollection, because they seemed to actually differentiate themselves. For the ImageCollection, I didn't actually extend CollectionBase, but instead just held on to an IList instance. So, the moral of the story is that TypeSafe collections can add value to a system, but they do come at a cost, and that cost should be weighed relative to the amount of effort necessary not only to [generate] the code, but also to maintain and especially to understand the system. Fewer extraneous types means fewer things to understand means a shorter ramp. I have included an example of a typical typesafe collection implementation from the .Text source code to demonstrate the amount of code we are talking about. It isn't a huge amount of code, until you realize that there are 14 other classes of identical size. Fortunately, the code is very much boilerplate, and there are many templating systems, e.g. CodeSmith, QuickCode, CodeRush, etc. that allow you to generate said boilerplate.

using System;
using System.Collections;
using System.Xml;

namespace Dottext.Framework.Components
{
  [Serializable]
  public class KeyWordCollection: CollectionBase
  {

    public KeyWordCollection() 
    {
    }
    
    public KeyWordCollection(KeyWordCollection value)  
    {
      this.AddRange(value);
    }
    
    public KeyWordCollection(KeyWord[] value)
    {
      this.AddRange(value);
    }
    
    public KeyWord this[int index] 
    {
      get  {return ((KeyWord)(this.List[index]));}
    }
    
    public int Add(KeyWord value) 
    {
      return this.List.Add(value);
    }
    
    public void AddRange(KeyWord[] value) 
    {
      for (int i = 0;  (i < value.Length); i = (i + 1)) 
      {
        this.Add(value[i]);
      }
    }
    
    public void AddRange(KeyWordCollection value) 
    {
      for (int i = 0;  (i < value.Count); i = (i +  1))  
      {
        this.Add((KeyWord)value.List[i]);
      }
    }
    
    public bool Contains(KeyWord value) 
    {
      return this.List.Contains(value);
    }
    
    public void CopyTo(KeyWord[] array, int index) 
    {
      this.List.CopyTo(array, index);
    }
    
    public int IndexOf(KeyWord value) 
    {
      return this.List.IndexOf(value);
    }
    
    public void Insert(int index, KeyWord value)  
    {
      List.Insert(index, value);
    }
    
    public void Remove(KeyWord value) 
    {
      List.Remove(value);
    }
    
    public new KeyWordCollectionEnumerator GetEnumerator()  
    {
      return new KeyWordCollectionEnumerator(this);
    }
    
    public class KeyWordCollectionEnumerator : IEnumerator  
    {
      private  IEnumerator _enumerator;
      private  IEnumerable _temp;
      
      public KeyWordCollectionEnumerator(KeyWordCollection mappings)
      {
        _temp =  ((IEnumerable)(mappings));
        _enumerator = _temp.GetEnumerator();
      }
      
      public KeyWord Current
      {
        get {return ((KeyWord)(_enumerator.Current));}
      }
      
      object IEnumerator.Current
      {
        get {return _enumerator.Current;}
      }
      
      public bool MoveNext()
      {
        return _enumerator.MoveNext();
      }
      
      bool IEnumerator.MoveNext()
      {
        return _enumerator.MoveNext();
      }
      
      public void Reset()
      {
        _enumerator.Reset();
      }
      
      void IEnumerator.Reset() 
      {
        _enumerator.Reset();
      }
    }
  }
}

* Profilers Are Your Friend.

Art, Comments, etc

File this under the category of blog vomit, cause it's gonna be a long one.

I like art that takes things out of context, especially text. I have an art project in my head that I have never taken the time to deliver on. The basic idea is this: Take two of those electronic scrolling marquee signs and a cable or satellite feed. From the feed, parse out the close captioning line, which I think is line 21 of the "Vertical blanking interval," at least for analog signals. I haven't research digital (this idea is several years old). On one of the signs, feed the live text from CNN, or possible CSPAN. On the other, feed the text from ESPN.

The difference is striking. One of my favorite things to do (though I seldom do it, because I don't really watch sports on TV) is to turn on some sport -- it really doesn't matter which, but catching John Madden commenting on football is really quite nice -- and then turn off the sound and on the closed captioning. The language is so very much like IM language, abbreviated, truncated, and overall mangled. It is pretty fascinating, really.

Well, this is neither closed captioned, nor is it a lovely, scrolling marquee, but it is a great forum for text art, I suppose. So, here is some text art out of context. Below are the comments from an upcoming open source project improving is releasing to the wild VerySoonNow(tm). We are very excited about this release, and I intend to be blogging about it more over the next couple of months.

Anyway, I was doing some refactoring on a converting an existing open source project as a related sample to the project we are releasing, and on a lark, I regexed all of the comments bye-bye. I like using the regex find/replace facilities for major restructurings (not refactoring, which I believe Martin Fowler would tell you is far more structured and far less risky.) Anyway, one thing lead to another, and I ended up chopping all of the comments out of the AssemblyInfo files in the projects, and then doing a find in files on "//," which of course yielded all of the remaining comments. I enjoyed reading them out of context, and I hope you will, too. I especially like some of the ones toward the end, as things start to sound dire... heh.

------------------------------------------------------

Find all "//", Subfolders, Keep modified files open, Find Results 2, Entire Solution, "*.*"

// TODO: Currently, the expression tree is visited by a

// string builder only. I wanted to avoid the visitor pattern

// I would like some kind of event based visitor approach.

// In visitor, double[or more] dispatch is the rule of the day,

// and when you start to add in complex conversions that

// are database specific, you get triple and quadruple dispatch.

// e.g. for stored procedures and parametric queries, I want

// new Expression("Name", "=", "Jef") to translate into

// "Name = @Name", where a IDbDataParameter (@Name, "Jef")

// is created

// This gets very awkward to implement cleanly, especially in

// light of things like where clauses, etc.

// The queries need to use parametric sql to support the best

// practice approach to avoiding sql injections attacks.

// doesn't work with type object.

// public static implicit operator Operand(object o)

// {

// return new Operand(o);

// }

//

// public static explicit operator object(Operand o)

// {

// return o == null ? null : o.Value;

// }

// TODO: Simple queries should work seamlessly with SameTableAssociations as well

// would need to be careful about recursive tables (i.e. adjacency models)

// only support configuring sql for fully metadata configured databases rather than individual

// maps, because configuring at the map level causes some dependency issues, especially with

// foreign keys being added to Child maps in the case of BackwardAssociation and Collection

// see Improving.Persistence.Metadata.Configurator.AssociateBackward or

// Improving.Persistence.Metadata.Configurator.AssociateMany for examples of where the dependencies

// occur

// TODO: Convert to stored procedures

//TODO: remove the sql2k-ism

// TODO: Doesn't support composite primary keys!

// TODO: Generate stored procedure for insert and delete

// TODO: Drop foreign keys from associative table to each of the mapped tables

// TODO: Add foreign keys from associative table to each mapped table

// TODO: This is currently coupled to the command adapter by assumption only

// would be nice if the two of these played well together

// (Note: I don't know exactly what I meant by this TODO: comment)

// TODO: Move this to the IMap

// TODO: could change this to be if map has id, then use that,

// else, if map has unique properties, then use that

// else, use all

// OR --

// just don't create it if the id doesn't exist

// btw -- disassociation for 1-1s is going to be hard. Could use the proxy generator.

//TODO: remove the sql2k-ism

// TODO: Consider ditching this class and the FindChildByParentBuilder class in favor of

// the generic FindByParameterBuilder. Also, consider renaming that to FindByPropertyBuilder

// TODO: invert control here. This code needs to be

// cleaned up. It doesn't currently support composite keys.

// TODO: Note that this implementation needs to be dependent on the identity strategy

// e.g. if the class doesn't have an identity column, the last statement is not valid.

// Remove sql2k-ism

/// <summary>

/// Implement this interface and pass instance to constructor of CommandAdapterFactory.

/// </summary>

// TODO: We explicitly assume that the names of the columns match on the two tables

// TODO: the expression creation code is copied from StatementBuilder

// "Don't repeat yourself"

// Also, fix the sql2k-ism

// This method assumes that the property is atomic, e.g. that it isn't a SameTableAssociation

// TODO: actually fill this object back up

// TODO: Load as it exists here is a bit restricting, because it limits the

// collection types to just IList implementors

// We want to be able to allow this differentiation to occur somewhere else,

// e.g. hanging somewhere off of Collection, so that we can support

// IDictionary, Queue, Stack, NameValueCollection, and friends

// TODO: I would really rather see this IdentityStrategy kept at the

// Map Identity level, but I currently don't because I don't want to pollute

// Property with an IdentityStrategy for ordinary properties, and

// I would also need to add the identity strategy for same table mappings

// as well

// Don't implement the property, because the Reflection.Emit libraries do not emit the property

// with the 'instance' attribute.

// e.g. the property IL looks like:

//

// property <IL Type> <Property Name>

//

// rather than

//

// property instance <IL Type> <Property Name>

//

// Overriding the property method implementations seems to get the desired effect, however.

// TODO: I added a hack here to quote the default string value. This is something that really needs to be

// handled somewhere in the Improving.DataProvider classes and their extensions, especially since conversion to

// the ddl and sql is database-specific

// Insert additional code to be run only when inserting values.

// Insert additional code to be run only when removing values.

// Insert additional code to be run only when setting values.

// First, we'll define the behavior of the "get" property for CustomerName as a method.

// Now, we'll define the behavior of the "set" property for CustomerName.

// Last, we must map the two methods created above to our PropertyBuilder to

// their corresponding behaviors, "get" and "set" respectively.

// Note that when invoking a property, you need to use the proper BindingFlags -

// BindingFlags.SetProperty when you invoke the "set" behavior, and

// BindingFlags.GetProperty when you invoke the "get" behavior. Also note that

// we invoke them based on the name we gave the property, as expected, and not

// the name of the methods we bound to the specific property behaviors.

// --- O U T P U T ---

// The output should be as follows:

// -------------------

// Property 'System.String CustomerName [System.String]' created!

// ---

// The customerName field of instance custData has been set to 'Joe User'.

// -------------------

// Insert additional code to be run only when inserting values.

// Insert additional code to be run only when removing values.

// Insert additional code to be run only when setting values.

// TODO: need to make all of these mappings work.

// AddDataType(typeof(System.DateTime),DbType.DateTime, "smalldatetime");

// AddDataType(typeof(System.DateTime),DbType.DateTime, "timestamp");

// AddDataType(typeof(System.String),DbType.String, "varchar");

// AddDataType(typeof(System.String),DbType.String, "ntext");

// AddDataType(typeof(System.String),DbType.String, "text");

name.CodeBase = @"file:///c:\";

// not sure this works as desired

// probably should propogate the transaction scope [somehow]

// refactoring notes:

// need provider for dialect (to come...)

// need map for ntuple dispatch

// don't need any System.Data specific bits

// other than commandtype

// TODO: proper logging

// TODO: Eval performance of this versus filling a DataSet

//TODO: The DataReaderStrategy ought to be pluggable

// TODO: Push IdentityStrategy into a special IdProperty class.

// IdProperty 1 ---> 1 IProperty

// Just a simple decorator

// TODO: Push IdentityStrategy into a special IdProperty class.

// IdProperty 1 ---> 1 IProperty

// Just a simple decorator

// TODO: Rename the file.

// TODO: Could potentially want to specify the Concrete Type here in the case of

// the Property Type being an abstract or at least base class.

// TODO: I have seriously considered using the metadata attributes as the embodiment of

// the mapping behavior. In this case, the only immediately obvious benefits are that

// you do not have separate metadata in the map heirarchy *and* the attributes

// and you don't have a hashtable lookup by type, though you do have a custom attribute

// lookup by type, the relative cost of which I am not sure of, and which, in the worst case

// would be mitigated by caching the results in a type indexed hashtable (heh).

// The thing I like about it is that I don't have to duplicate the heirarchy of the object graph

// in the mapping structure. I think that it is a good science fair project for later

// e.g. create a set of metadata attributes on a type that allows you to attach arbitrary behaviors

// to them

// The runtime performance would probably suck donkey balls, though.

/// <summary>

/// If the PersistentName is not provided, the PropertyName is used in it's place

/// If the DatabaseType is not provided, it defaults to the ADO Provider-specific default mapping for the type

/// Required defaults to true

/// Unique defaults to false

///

/// </summary>

// TODO: We currently asssume that the fk names are going to match on

// each table. That will be a problem later, but ignore it for now.

//

// TODO: Continue to grow this interface and then diff with IProperty, Association

// see if there is an appropriate refactoring

// TODO: maybe this load strategy should only be used by

// Associations, though esoteric things like text or blobs

// might need to be deferred from time to time

// TODO: We want this to add AssociativeTable parameters when inserting the associative table record

// but not when we are doing a regular

// TODO: If the backward association is navigated via an associative table,

// and the lifetimes of the two objects in the relationship are managed independently,

// then deleting either one needs to delete the the associations but not the other

// when navigating forward, this is relatively natural, just delete.

// when deleting the child in the backward association, the child map needs to be made aware of the

// existence of the parent. This is currently managed by the existence of the ForeignKey instance in the

// child map. This object should know how to delete the association.

// TODO: Not so sure the property name is important here

// TODO: Decouple this

// TODO: If the strategy is an AssociativeTable, CascadeSaves must be true

// TODO: This is a bit incongruent with the other uses of sql being hidden in the

// command adapter, but, simplest thing, simplest thing!

// TODO: IT WOULD BE NICE TO BE ABLE TO LEVERAGE THE

// IProperty TO ADD PARAMETERS TO THE QUERY

// BUT I DON'T HAVE A COMMAND RIGHT NOW

// TODO: this is a hack

// TODO: this down cast needs to go.

// TODO: Here, we don't want to read just yet. We want to let the foreign key read this part

// because it could be that we have a composite foreign key

// TODO: this could come back to haunt us when we start adding recursive references (e.g. tree nodes)

// TODO: Implement more than one level of inheritance

// The default, do nothing version of inheritance is to

// map each class to it's own table. In this case, we should *not*

// configure the superclass, because

// TODO: Need to check the class's persistent attr to see whether there should be a default mapping

// in the abscense of a property's persistent attr.

// Need to create a metadata navigation utility. This code is going to be very ugly otherwise.

// TODO: Need to get the semantics right for this. Add more attribute types for now

// The intermap dependencies (i.e. associations) are going to make it necessary to either

// sort the maps by dependency and configure them in least-to-most dependent order

// or be able to recursively kickoff a Configure(Type t) for each Association that is guarded to ensure

// that types are processed once and only once.

// TODO: Colocate the attributes with the configuration code rather than the metadata mapping code,

// add a polymorphic method to the PersistentAttribute, and push the code below into the

// polymorphic method

// TODO: Map Configurator currently assumes the naming strategy adopted in

// Imp.Persistence.Sql.Generation but the coupling is loose

// TODO: Need to be able to specify cascade semantics. Currently, everything defaults to true.

// TODO: Currently, we assume that the fk a) exists in the child table and b) uses exactly the same naming convention

// This strategy mirrors the object model in the database

// which is to say that for each class, abstract or not,

// it expects a table. One of the things I am struggling with

// is that, at runtime, we don't really [need to] care about the fact that

// the object is spread across two different tables, except possibly

// in the case of dynamic queries. Even that should be ignorable by

// having a base FindAll query to jump start the dynamic query.

// But we do need it at sql-gen time, and we do need it at configuration

// time, especially if we aren't using attributes.

// TODO: Remove the SQL2K-ism

// TODO: I believe that this is a sql2k-ism

// [ [ [ server. ] [ database ] . ] [ owner_name ] . ] object_name

// TODO: This "@" sql2k-ism needs to be farmed out to the Provider

// not supported -- map.Properties.Add(new Property("new Property("CharProp = 'y';

//TODO: need to add lengths to types, deal with dbtypes properly

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

// TODO: THIS ONE IS GOING TO FAIL BECAUSE OF THE NEED FOR [Order] in the select query

// BUT I NEEDED TO REMOVE IT FOR THE INFORMATION SCHEMA BECAUSE IT NEEDS AN Identifier

//TODO: use property name instead of column name

//TODO: shouldn't have to quote strings

//TODO: should convert dynamic sql values to named parameters that are set

//TODO: abstract the dialect from the ansi sql model from the generic expression model

// not supported -- primitive.CharProp = 'y';

primitive.DecimalProp = 0; //Decimal.MaxValue;

// TODO: Move this adjustment into a datetime IProperty implementation so that the framework

// always deals consistently with datetimes. Of course, it is specific to the database, i.e. sql2k,

// so there needs to be some coordination between the provider and the properrty.

ImpWare\Default.aspx(2):<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >

ImpWare\Default.aspx(10): <meta name=vs_targetSchema content="http://schemas.microsoft.com/intellisense/ie5">

/// <summary>

/// Summary description for _Default.

/// </summary>

// Put user code to initialize the page here

//

// CODEGEN: This call is required by the ASP.NET Web Form Designer.

//

/// <summary>

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

/// </summary>

/// <summary>

/// Summary description for Global.

/// </summary>

/// <summary>

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

/// </summary>

/// <summary>

/// Summary description for Login.

/// </summary>

// Put user code to initialize the page here

//

// CODEGEN: This call is required by the ASP.NET Web Form Designer.

//

/// <summary>

/// Required method for Designer support - do not modify

/// the contents of this method with the code editor.

/// </summary>

/// <summary>

/// Summary description for SecurityDbConfigurator.

/// </summary>

// TODO: need to roll the strategy and the creation of the service providers into one

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

//------------------------------------------------------------------------------

// <autogenerated>

// This code was generated by a tool.

// Runtime Version: 1.1.4322.12

//

// Changes to this file may cause incorrect behavior and will be lost if

// the code is regenerated.

// </autogenerated>

//------------------------------------------------------------------------------

// TODO: Consolidate QualifiedName and Identifier

// TODO: Design note: We may very well have legitimate columns in the database that

// we do not want to load into the application, nor do we want to make the application

// aware of them. This is going to cause difficulties in the difference engine.

// We are primarily concerned with getting the object model right.

// If nullable fields exist in the database but not in the object model, things may be cool.

// If nullable fields exist in the object model, but not in the database, we may be

// able to gracefully degrade as well.

// Some other problems that I thought about: Basically, it may not make sense to try to diff with a

// single map. It probably has to be a whole Database instance.

// TODO: Decouple this into a real unit test, i.e. minimize dependencies on

// improving.domain.security

// TODO: Currently, the expression tree is visited by a

// TODO: Need to add the simple query generation interface

//TODO: Make Backward FindChildByParent composite key aware

// TODO: Need to generate foreign key constraints at the end of the script

// TODO: Need to generate drop foreign key constraints at the beginning of the script

// TODO: Need to be able to use associative tables in (1-* | *-*) relationships

// TODO: handle composite keys

// TODO: refactor into

// TODO: This is currently coupled to the command adapter by assumption only

// TODO: Move this to the IMap

// TODO: could change this to be if map has id, then use that,

// TODO: need to append, e.g. INFORMATION_SCHEMA and/or deal with aliased table names

// TODO: Remove sql2k-ism

// TODO: actually fill this object back up

// TODO: Load as it exists here is a bit restricting, because it limits the

// TODO: I would really rather see this IdentityStrategy kept at the

// TODO: I added a hack here to quote the default string value. This is something that really needs to be

// TODO: proper logging

// TODO: fix sql injection attack here.

// TODO: Eval performance of this versus filling a DataSet

// TODO: I have seriously considered using the metadata attributes as the embodiment of

// TODO: Add constructor logic here

// TODO: maybe this load strategy should only be used by

// TODO: Add primitive maps

// TODO: Decouple this

// TODO: This is a bit incongruent with the other uses of sql being hidden in the

// TODO: IT WOULD BE NICE TO BE ABLE TO LEVERAGE THE

// TODO: this is a hack

// TODO: this down cast needs to go.

// TODO: IS THIS RIGHT?? THIS FRAMEWORK IS GETTING DIZZYING

// TODO: Here, we don't want to read just yet. We want to let the foreign key read this part

// TODO: this could come back to haunt us when we start adding recursive references (e.g. tree nodes)

// TODO: Need to track the created maps internally

// TODO: Need to get the semantics right for this. Add more attribute types for now

// TODO: Map Configurator currently assumes the naming strategy adopted in

// TODO: Currently, we assume that the fk a) exists in the child table and b) uses exactly the same naming convention

// TODO: Remove the SQL2K-ism

// TODO: I believe that this is a sql2k-ism

//TODO: need to add lengths to types, deal with dbtypes properly

// TODO: THIS ONE IS GOING TO FAIL BECAUSE OF THE NEED FOR [Order] in the select query

//TODO: use property name instead of column name

//TODO: shouldn't have to quote strings

//TODO: should convert dynamic sql values to named parameters that are set

//TODO: abstract the dialect from the ansi sql model from the generic expression model

// TODO: need to roll the strategy and the creation of the service providers into one

Total found: 429 Matching files: 78 Total files searched: 268

Catching up

Tons of good stuff to read:

Clemens Vasters returns to his blogging life with two great posts [more to follow] on dealing with transactions and deadlocks using messaging. I implemented a similar approach in the messaging framework I built earlier this year. The framework that Clemens is demonstrating fairly easily extends beyond database transactions and related transient failures to supporting general transient availability issues with arbitrary components, such as sockets, queues, etc. If he doesn't end up going there, I will post a bit more on extending his good ideas.

On the RestWiki, Mark Baker discusses an epiphanic moment when he is schooled in the art of network apis by Mr. Roy Fielding. The post is a thing of beauty. Cool. I feel schooled, and I thought I got the REST v. SOAP, messaging v. RPC arguments. Tim Ewald is a fountain of great posts lately, and Roy's reply to Mark above is, to me, an exact, brief explanation of what TimE is digging into with his threads on SO vs. OO and Semantics in WS[A].

All of the posts are the recent ones on his blog, but links to individual posts provided here for convenience. The comments are worth the read as well.

SO v. [D]OO: 1, 2, 3, and 4

Semantics: 1, 2, 3, and 4

I have started and stopped about 4 replies to these posts with considerably more commentary than the mere acknowledgement here, and each time I have learned something new that has forced me to rethink my post. Perhaps I will get the thoughts out this weekend.