For our test scenarios - based on configuration of the application, we may want to either enable or disable a scenario. For this purpose, I created a custom IgnoreIfConfig Attribute like this :
public class IgnoreIfConfigAttribute : Attribute, ITestAction
{
public IgnoreIfConfigAttribute(string config)
{
_config = config;
}
public void BeforeTest(ITest test)
{
if (_config != "Enabled") NUnit.Framework.Assert.Ignore("Test is Ignored due to Access level");
}
public void AfterTest(ITest test)
{
}
public ActionTargets Targets { get; private set; }
public string _config { get; set; }
}
Which can be used as follows :
[Test, Order(2)]
[IgnoreIfConfig("Enabled")] //Config.Enabled.ToString()
public void TC002_DoTHisIfEnabledByConfig()
{
}
Now This attribute would only take a constant string as an input. If I were to replace this with something generated dynamically at the runtime, Such as a value from Json file - How can I convert it to a Constant. Constant Expression, TypeOf Expression or Array Creation Expression of Attribute parameter type ? Such as Config.Enabled ?
You can't do as you asked but you can look at the problem differently. Just give the attribute the name of some property in the JSON file to be examined, e.g. "Config".
As per Charlie's suggestion : I implemented it like this -
PropCol pc = new PropCol(); // Class where the framework reads Json Data.
public IgnoreIfConfigAttribute(string config)
{
pc.ReadJson();
if(config = "TestCase") _config = PropCol.TestCase;
// Here TestCase is a Json element which is either enabled or disabled.
}
I'm trying to get some help on deserializing a JSON reponse to a DataSet.
in theory this should be easy as using this example
http://www.newtonsoft.com/json/help/html/DeserializeDataSet.htm
DataSet dataSet = JsonConvert.DeserializeObject<DataSet>(json);
DataTable dataTable = dataSet.Tables["Table1"];
However the JSON I am getting back is supplemented / decorated using "odata.metadata"
see below.
{"odata.metadata":"http://nodts004.cloudapp.net:7058/TNPMaster2016Dev/OData/$metadata#NP_Customer","value":[{"No":"01121212","Name":"Spotsmeyer's Furnishings","City":"Miami","Amount":"0","Customer_Posting_Group":"FOREIGN","Balance_LCY":"0","Sales_LCY":"0","Profit_LCY":"0","Balance_Due_LCY":"0","Payments_LCY":"0","Inv_Amounts_LCY":"0","Cr_Memo_Amounts_LCY":"0","Outstanding_Orders":"0","Shipped_Not_Invoiced":"0","No_of_Quotes":0,"No_of_Blanket_Orders":0,"No_of_Orders":6,"No_of_Invoices":0,"No_of_Return_Orders":0,"No_of_Credit_Memos":0,"No_of_Pstd_Shipments":0,"No_of_Pstd_Invoices":0,"No_of_Pstd_Return_Receipts":0,"No_of_Pstd_Credit_Memos":0,"No_of_Ship_to_Addresses":0,"Outstanding_Orders_LCY":"0","Shipped_Not_Invoiced_LCY":"0"},{"No":"01445544","Name":"Progressive Home Furnishings","City":"Chicago","Amount":"0","Customer_Posting_Group":"FOREIGN","Balance_LCY":"1499.02","Sales_LCY":"1499.02","Profit_LCY":"305.12","Balance_Due_LCY":"1499.02","Payments_LCY":"0","Inv_Amounts_LCY":"1499.02","Cr_Memo_Amounts_LCY":"0","Outstanding_Orders":"0","Shipped_Not_Invoiced":"0","No_of_Quotes":0,"No_of_Blanket_Orders":0,"No_of_Orders":0,"No_of_Invoices":0,"No_of_Return_Orders":0,"No_of_Credit_Memos":0,"No_of_Pstd_Shipments":1,"No_of_Pstd_Invoices":1,"No_of_Pstd_Return_Receipts":0,"No_of_Pstd_Credit_Memos":0,"No_of_Ship_to_Addresses":0,"Outstanding_Orders_LCY":"0","Shipped_Not_Invoiced_LCY":"0"},{"No":"01454545","Name":"New Concepts Furniture","City":"Atlanta","Amount":"0","Customer_Posting_Group":"FOREIGN","Balance_LCY":"222241.32","Sales_LCY":"0","Profit_LCY":"0","Balance_Due_LCY":"222241.32","Payments_LCY":"0","Inv_Amounts_LCY":"222241.32","Cr_Memo_Amounts_LCY":"0","Outstanding_Orders":"15609","Shipped_Not_Invoiced":"0","No_of_Quotes":0,"No_of_Blanket_Orders":0,"No_of_Orders":1,"No_of_Invoices":0,"No_of_Return_Orders":0,"No_of_Credit_Memos":0,"No_of_Pstd_Shipments":0,"No_of_Pstd_Invoices":0,"No_of_Pstd_Return_Receipts":0,"No_of_Pstd_Credit_Memos":0,"No_of_Ship_to_Addresses":0,"Outstanding_Orders_LCY":"8702.82","Shipped_Not_Invoiced_LCY":"0"},{"No":"01905893","Name":"Candoxy Canada Inc.","City":"Thunder Bay","Amount":"0","Customer_Posting_Group":"FOREIGN","Balance_LCY":"0","Sales_LCY":"0","Profit_LCY":"0","Balance_Due_LCY":"0","Payments_LCY":"0","Inv_Amounts_LCY":"0","Cr_Memo_Amounts_LCY":"0","Outstanding_Orders":"0","Shipped_Not_Invoiced":"0","No_of_Quotes":0,"No_of_Blanket_Orders":0,"No_of_Orders":0,"No_of_Invoices":0,"No_of_Return_Orders":0,"No_of_Credit_Memos":0,"No_of_Pstd_Shipments":0,"No_of_Pstd_Invoices":0,"No_of_Pstd_Return_Receipts":0,"No_of_Pstd_Credit_Memos":0,"No_of_Ship_to_Addresses":0,"Outstanding_Orders_LCY":"0","Shipped_Not_Invoiced_LCY":"0"},{"No":"01905899","Name":"Elkhorn Airport","City":"Elkhorn","Amount":"0","Customer_Posting_Group":"FOREIGN","Balance_LCY":"0","Sales_LCY":"0","Profit_LCY":"0","Balance_Due_LCY":"0","Payments_LCY":"0","Inv_Amounts_LCY":"0","Cr_Memo_Amounts_LCY":"0","Outstanding_Orders":"0","Shipped_Not_Invoiced":"0","No_of_Quotes":0,"No_of_Blanket_Orders":0,"No_of_Orders":0,"No_of_Invoices":0,"No_of_Return_Orders":0,"No_of_Credit_Memos":0,"No_of_Pstd_Shipments":0,"No_of_Pstd_Invoices":0,"No_of_Pstd_Return_Receipts":0,"No_of_Pstd_Credit_Memos":0,"No_of_Ship_to_Addresses":0,"Outstanding_Orders_LCY":"0","Shipped_Not_Invoiced_LCY":"0"}]}
I have for certain scenarios created a POCO to deal with the returned json for the properties
public class RootObject2
{
[JsonProperty("odata.metadata")]
public string odatametadata { get; set; }
[JsonProperty("odata.nextLink")]
public string NextLinkUrl { get; set; }
}
and
public class RootObject
{
[JsonProperty("odata.metadata")]
public string odatametadata { get; set; }
[JsonProperty("odata.nextLink")]
public string NextLinkUrl { get; set; }
public List<UrlItem> Value { get; set; }
}
These are used in instances where I know the returned JSON will contain certain structures and can be safely dealt with.
The problem is that the VALUE part of the JSON will be dynamic in many instances and I wanted to take advantage of the dynamic nature of the JSONConvert functions to build DataSets that I can then pass through as a source for an Excel table. It should be noted that the data coming back will never be definable.
When i use the code:
DataSet dataSet = JsonConvert.DeserializeObject<DataSet>(json);
I get an error, because I need to be passing the sting / contents of the VALUE node/element to the DeserialseObject.
Is there a setting on the JSON converter that allows this?
I have tried to create a POCO with a string field and then after mapping the VALUE node to the POCO passing the string to the JSONConverter but this errors out.
A solution to this would be most helpful.
Thanks.
B....
You can create your own custom subclass of DataSetConverter that strips out non-array-valued properties from the root DataSet object:
public class DataSetConverter : Newtonsoft.Json.Converters.DataSetConverter
{
public override bool CanConvert(Type valueType)
{
if (!base.CanConvert(valueType))
return false;
return typeof(DataSet).IsAssignableFrom(valueType);
}
public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
{
if (reader.TokenType == JsonToken.Null)
{
return null;
}
var token = JObject.Load(reader);
// Strip non-array-valued properties
foreach (var property in token.Properties().Where(p => p.Value.Type != JTokenType.Array).ToList())
property.Remove();
using (var subReader = token.CreateReader())
{
while (subReader.TokenType == JsonToken.None)
subReader.Read();
return base.ReadJson(subReader, objectType, existingValue, serializer); // Use base class to convert
}
}
}
Then use it as follows:
var dataSet = JsonConvert.DeserializeObject<DataSet>(json, new JsonSerializerSettings { Converters = new JsonConverter[] { new DataSetConverter() } });
var dataTable = dataSet.Tables["value"];
Prototype fiddle.
I have a lots of DTOs that must be mapped to my domain's objects. In general, the mapping to monetary values need to apply a rounding rule. That's apply for more than 95% of the cases, but I have some data that need a different rounding rule. I was planned to do the next:
1) Create a ITypeConverter for the general rounding rule, that apply for default in for this type conversions.
2) Create a ValueResolver for the special rounding cases, and specify their use in the member mapping.
I created a test case to try my approach, but after the application of the ValueResolver for the special cases, AutoMapper uses the TypeConverter to get the final value, using the general rule.
That's a wrong approach?? May be I'm missing something??
Then the test case:
[TestFixture]
public class RoundingTests
{
public class MoneyConverter : ITypeConverter<decimal, decimal>
{
public decimal Convert(ResolutionContext context)
{
return Math.Round((decimal)context.SourceValue, 2, MidpointRounding.AwayFromZero);
}
}
public class Money12Resolver : ValueResolver<decimal, decimal>
{
protected override decimal ResolveCore(decimal source)
{
return Math.Round(source, 12, MidpointRounding.AwayFromZero);
}
}
public class PercentResolver : ValueResolver<decimal, decimal>
{
protected override decimal ResolveCore(decimal source)
{
return Math.Round(source, 4, MidpointRounding.AwayFromZero);
}
}
internal class Source
{
public decimal Price { get; set; }
public decimal Percent { get; set; }
public decimal Prorate { get; set; }
}
internal class Destination
{
public decimal Price { get; set; }
public decimal Percent { get; set; }
public decimal Prorate { get; set; }
}
[Test]
public void MappingTest()
{
Mapper.CreateMap<decimal, decimal>().ConvertUsing<MoneyConverter>();
Mapper.CreateMap<Source, Destination>()
.ForMember(d => d.Percent, o => o.ResolveUsing<PercentResolver>().FromMember(s => s.Percent))
.ForMember(d => d.Prorate, o => o.ResolveUsing<Money12Resolver>().FromMember(s => s.Prorate));
Mapper.AssertConfigurationIsValid();
var source = new Source
{
Price = 12345.6789m,
Percent = 0.123456m,
Prorate = 123.123451234512345m
};
var convertion = Mapper.Map<Destination>(source);
Assert.That(convertion, Is.Not.Null);
Assert.That(convertion.Price, Is.EqualTo(12345.68m));
Assert.That(convertion.Percent, Is.EqualTo(0.1235m));
Assert.That(convertion.Prorate, Is.EqualTo(123.123451234512m));
}
}
Test Result:
Expected: 0.1235m
But was: 0.12m
You're telling AutoMapper to convert all decimal->decimal mappings using your MoneyConverter. AutoMapper does, in fact, use your resolver (set a break point to see), but the result of resolving is a decimal value that is then used by the MoneyConverter you applied.
Note: This appears to be the design of AutoMapper; I don't see a way to override a type converter.
Not all of your decimal properties represent money, so you may want to take a different approach. Also ask yourself, are you rounding purely for values used for presentation, or are you potentially losing precision you'd want to retain in those domain objects? If you really need the rounding, you could be explicit and set a resolver per member, skipping the converter completely. Alternatively, you could ignore the members which are exceptions and handle that with a .ConstructUsing(...).
But since your original question relates to using a Resolver and Converter for the same type, here's one way you can make it work:
Basically we want the converter to skip the default conversion for certain properties. We can't do it via configuration, so we'll have to do it at run-time. Assuming you have access to the Destination class, just decorate properties with non-default behavior using a custom attribute.
class PercentAttribute : Attribute
{ }
class Destination
{
[Percent]
public decimal Percent { get; set; }
...
}
In your converter, you can then look for properties which are [Percent] and return the source value, which came from your PercentResolver.
public class MoneyConverter : ITypeConverter<decimal, decimal>
{
public decimal Convert(ResolutionContext context)
{
var propInfo = context.PropertyMap.DestinationProperty.MemberInfo;
bool isPercent = propInfo.GetCustomAttributes(typeof(PercentAttribute), true).Any();
if (isPercent) return (decimal)context.SourceValue;
return Math.Round((decimal)context.SourceValue, 2, MidpointRounding.AwayFromZero);
}
}
If you're going to go that route, just have the converter do Money, Percent, and Money12 conversions based on attributes, and skip the resolvers completely.
I'm using Fluent NHibernate (1.2.0.712) and Nhibernate.Linq (version 1) with SQLite (1.0.79)
Here is my model:
public class QueueItem
{
public virtual long ID { get; set; }
public virtual DateTime AddedToQueue { get; set; }
public virtual DateTime DontProcessUntil { get; set; }
public virtual DataQueueItemState State { get; set; }
}
Note that the ID is a long.
I also have this bit of LINQ:
var nextID =
from i in _repository
where i.State == DataQueueItemState.GetDataQueue && i.DontProcessUntil < DateTime.UtcNow
group i by i.State into g
select new { ID = g.Min(i => i.ID) };
_repository is a data layer repository implementing IQueryable.
This query works fine. However, when I looked at the generated SQL, I saw this:
NHibernate: select cast(min(queueitem0_.ID) as INTEGER) as col_0_0_ from "QueueItem"
queueitem0_ where queueitem0_.State=#p0 and queueitem0_.DontProcessUntil<#p1 group by
queueitem0_.State;#p0 = 'GetDataQueue' [Type: String (0)], #p1 = 28/03/2012 08:21:10
[Type: DateTime (0)]
The question is; why is the ID getting cast to an INTEGER?
In fact, why is it casting at all?
On the code side, the g.Min(i => i.ID) knows that it is returning a long.
A new anonymous type is being generated to hold the result and if I do a .elementAt(0).ID on it then it gives me a long as well so that all seems fine.
You are seeing the conversion because long is not a sql data type. I understand that your SQLite columns can be typeless with exception to the ID but NHibernate converts .NET data types to their sql equivalent. I would suggest using Int64 instead of long just to be safe but this is expected behavior.