This project is read-only.

Feature Tracker

May 17, 2012 at 1:42 PM
Edited May 17, 2012 at 1:44 PM

Just an idea...

Is there a place where I could post my features wish list, along with the community, and the community could Vote on the features they want next? And this would give weight to new features and road map nHydrate.  Also the feature tracker will self document the features you already have.

This is my second day, and I love nHydrate and where it can lead.  I've even contributed a donation.

For instance:

  1. one niggly pet hate of EF is when you save a string value that has a length greater than the column width.  It would be nicer, if the code generated (template/framework) could automatically handle this in one of three ways at the developers choosing. 

    Namely either;
    a. Just truncate the value (nasty),
    b. or throw a more meaningful exception (note the one that LINQ to SQL throws, is a generic SQL truncation error and no indication as to which field(s)/column(s) that triggered it.  This can be captured by the developer or nHydrate framework, and dealt with, ie: stop the transaction, email the developer, log the error etc. (preferred)
    c. or truncate the value and handle the overflow, ie: have a Text column, with for example a JSON string of overflowed values.  (over-kill for either bad data or poor design choice) (Framework will have to handle this so that the it reads/writes from/to the database overflow column, but the app can keep running as normal.)

  2. use nHydrate to model non-database specific classes.  Ie: as a class designer, but driven by nominated tables/fields from your current database model.  For example you map a database table (or two) and some fields from that table, to a class/properties designer.  This will then code generate, perhaps via a T4 template all the classes that will be used by say a WCF Web Service.  The constructor of these class could then take the EFDAL Entity name and map the values to the data class, which is returned to the Web Service client.

    Or model MVC Model classes.

  3. use nHydrate to model other data structures like CSV, XML, Fixed Width text files, but code generate classes and/or map to other nHydrate models like to a database model.  So one could model the dataflow from say a CSV file straight to a database table, and do very little code to implement that.


Anyways, I'm getting carried away here... 

Just a bunch of ideas I need to get out of my head so I can get back to work.  Cheers.

May 19, 2012 at 3:24 AM
Edited May 19, 2012 at 3:27 AM

Point 1 is already implemented. When a property is set, it is validated. Keep in mind this occurs even before persist to database. For example if a field is defined as varchar(50) and if you set a string that is 50+ characters, it will throw an exception on the setter. However you can also choose to truncate. Here are some example of how to set a property and how to set it with truncation.

//Create new object
var item = new Customer();

//Set normally (will throw error if too big)
item.Field1 = "Hello";

//Set by field enumeration
item.SetValue(FieldNameConstants.Field1, "Hello"); //(will throw error if too big)
item.SetValue(FieldNameConstants.Field1, "Hello", true); //(truncate if too big)

//Set by lambda selector
item.SetValue<string>(x => x.Field1, "Hello"); //(will throw error if too big)
item.SetValue<string>(x => x.Field1, "Hello", true); //(truncate if too big)


We are still discussing points 2 and 3.