Many users of Paul Wilson’s O/R mapper (“WORM”) know that there are a number of community-provided patches which are out there but not incorporated in any official release. Personally, I have maintained a copy of the source code in a private Subversion repository and incorporated a number of these patches for my own use. (Access to the full source code of WORM require you to pay a very reasonable $50 “subscriber fee” to Paul Wilson.)
I contacted Paul Wilson yesterday, asking him if he’d let me grant access to this repository to people who are WORM subscribers. Fortunately for all involved, he said yes!
What does this mean for you? If you are a subscriber to WORM, you can send me your full name and email address and request access to this private repository. I will confirm your subscription with Paul and grant you access.
The following changes have been incorporated into the aforementioned WORM instance:
- Based on the 188.8.131.52 Subscriber Preview.
- Unnecessary SELECT COUNT(*) calls removed (see reference post).
- Performance using large data sets improved (see reference post).
- A few other small changes and tweaks.
The purpose of opening up this Subversion repository to subscribers is to give us all a place to share and contribute to a central copy of WORM that includes all the improvements and patches we maintain individually.
If you want to participate, send me your full name and email address.
0 thoughts on “Wilson.ORMapper subscriber source code repository”
OMG this is such good news! Email on its way.
Do you have a Contact page or whats your email address?
Email me at email@example.com.
I sent you an e-mail to be added.
Also, what are your thoughts on WORM v. Linq to SQL? It appears, perhaps I’m wrong, that Paul himself has abandoned his ORM for it … and if so, I’d really like to know why. Personally, there are THREE primary reasons I’m hesitant to leave WORM in lieu of Linq and they are as follows:
1. Database support
LtS is for SQL Server only! For most of my stuff that is fine. But I like the fact that I can, more or less, simply change the provider in WORM if I move to a different DBMS. Heck, I like the ability to start with a different DBMS to begin with.
2. Architecture flexibility
LtS imposes an Active Record pattern which is fine and generally sufficient (think of Ruby on Rails success). But I like the ability to choose either Active Record or Data Mapper. In fact, if I have to move my objects accross a web service I prefer for the clients to not see or be bothered with attributes indicating how particular classes and properties map to my database tables and columns. WORM and WORW make that a possibility … LtS does not insofar as I can see.
The mapping/code generation for WORM/W, at least for me, get things off the ground fast!
With regards to LtS … I do like many of the features not included in WORM and perhaps they can be incorporated (joins, ability to query objects with added intellisense, etc…). Still, even with Linq … I’m leaning to sticking with WORM.
And while I’m thinking of it. A couple of suggestions about improving WORM/W:
1. Ability to define a One-To-One mapping
2. Linq to WORM (i.e., like the one built for NHibernate recently featured on MSDN).
3. A CastleProject type Validation Attribute library for properties.
4. Better documentation! There are several issues people are continually battling with regarding WORM … putting a library of articles (e.g. how to do a one-to-one, when you should/shouldn’t use Helper, how to do optimistic concurrency, etc…) could be helpful for everyone!
Anyways, these are my thoughts currently … what say you all???
I agree that MSSQL-only support is damaging — being unable to use more than one database platform with a data mapper is not a viable option for me, as I am more focused on using MySQL than MSSQL (mostly thanks to price differences). I haven’t done an incredible amount of research into LINQ to SQL, but that one reason will stop me from looking too heavily into it.
I agree that WORM’s benefit is its simplicity — it takes very little time to get going. Then again, lots of products offer this once you are familiar with them. Still, I prefer WORM/WORW even after trying some well-established alternatives.
On WORM improvements…
1) One-to-one is something that can probably be incorporated into WORM without a lot of effort, and would bring immediate value.
3) Validation I feel is best left outside the O/R mapper — using Castle Validation library or the EntLib validation library should suffice. Why recreate the wheel? Did you know the current WORW templates support a “validators” attribute in the mapping file, as in the following:
Whatever is in the validators attribute would be added as a C# attribute. So, the above adds [ValidateNonEmpty(), ValidateLength(2,20)] as a C# attribute on the UserName property. (That example uses the Castle validation library.)
4) Most public projects have documentation issues, WORM/WORW included. 🙂