In my AutoQuery service, one of my request DTOs uses a custom "NameSearch" property with a QueryField attribute with a Template which has ORs in it - "FirstName LIKE {Value} OR LastName LIKE {Value} OR ..." . I also have a boolean property "IsActive" which matches a field in the database table.

When I use these two properties together in a query to the service - "?NameSearch=abc&IsActive=true" - the results contain some people who are inactive. I should have figured this out without a SQL trace, but when I did one, I noticed that this was caused by not having parentheses around the NameSearch Template string (the ORs where the problem).

Of course, the fix is to always place parentheses around any Templates in QueryField attributes, but I wonder if we might "get that for free" so that my sometimes feeble mind doesn't have to remember?

Thanks!

Current transaction isolation levels do not prevent others from reading and modifying the same data.
They all wait nice in line to be able to update the same rows, but there is no way of preventing them from overwriting the previous data, and no error message that the data you selected has become stale in between.

An easy way to solve it to allow a way to lock the selected rows to assure that the current transaction is finished before the next one can read the value and do its own changes.

This is easely done by just adding a small statement to the select SQL:

MySQL,PosgreSQL,Oracle: "FOR UPDATE" at the end
SQL Server: "WITH (updlock)" before WHERE

I am using ServiceStack with Autofac IoC.
There is code provided for wiring up the AutofacIocAdapter as the default resolver for ServiceStack (instead of Funq).
There are two method currently exposed on the IContanerAdapter interface which is used to expose wiring.
It would be useful to expose another method to resolve registered components with named parameters .
It would be very easy as the underlying IContainer interface already exposes this methed.

So, something like

public class AutofacIocAdapter : IContainerAdapter
{
private readonly IContainer _container;

public AutofacIocAdapter(IContainer container)
{
_container = container;
}

public T Resolve<T>()
{
return _container.Resolve<T>();
}

public T Resolve<T>(NamedParameter parameter)
{
return _container.Resolve<T>(parameter);
}

public T TryResolve<T>()
{
T result;

if (_container.TryResolve<T>(out result))
{
return result;
}

return default(T);

}

}

where public T Resolve<T>(NamedParameter parameter) method would be the new method to expose

This feature is useful when you need to do STRING related operations on NON STRING types like INT.

One use case is when you need to do pattern matching (used in searches) on an INT column. That would be great to be able to just write:

q.Where(x => x.IntColumn.ToString().Contains("123"));

which should generate the following in SQL Server:

WHERE cast(IntColumn as VARCHAR) LIKE '%123%'

Since this feature is not implemented we have to use something like this:

q.Where("cast(IntColumn as VARCHAR) LIKE '%123%'");

Which is not that good because it is not strongly typed. And also for that SqlExpression to work, OrmLiteUtils.IllegalSqlFragmentTokens needs to be modified to exclude dangerous keywords like "cast".

Similar feature in NHibernate: https://nhibernate.jira.com/browse/NH-2563

RAML (see raml.org) is pretty sweet as a design tool... like Swagger 2.0, you can design your full API and corresponding documentation in the designer tools.

It would be nice to have ServiceStack support reading RAML generated specs and automagically create the corresponding ServiceStack API with stubbed in methods.

One of the nice things about RAML is the ability to generate a mock JSON responses and/or status codes from a specified endpoint as directed by the RAML designer tools. This allows it easy for other peer developers (and regression tools) to consume your service although it might still be under development or is incomplete.

Currently ExcludePropertyReferences is expecting DeclaringTypeName.DataContractName. Its more helpful if the type is fully qualified.

for example ; from below Json if we want to exclude :{"Officeaddress.houseaddress.city"}; .

Json:
//----------------------------------------------------------------------------
{"id":"eb26f100-3758-4a19-806b-cd5af44f88a4","data":{"lname":"Talluri","firstname":"RamaNaresh","city":"Atlanta"},"collections":{"houseaddress":[{"id":"126e057d-e91b-42ec-b40d-bdba9c831d64","data":{"city":"CA_Toronto"}}],"officeaddress":[{"id":"5ff48bd4-bfe2-4721-adf1-3f5cd3b5c736","data":{"city":"US_Alpharetta"},"collections":{"houseaddress":[{"id":"aad21efc-2768-4518-a505-71dc8b82ad40","data":{"city":"CA_Downtown"}}]}}]}}
//----------------------------------------------------------------------------
Model :
//----------------------------------------------------------------------------
[DataContract]
public class AddressModel : BaseModel
{
[DataMember(Name = "id")]
public System.Guid Id
{
get;
set;
}

[DataMember(Name = "data")]
public virtual BaseAddress Data
{
get;
set;
}

[DataMember(Name = "collections")]
public virtual AddressCollection Collections
{
get;
set;
}
}

[DataContract]
public class BaseAddress
{

[DataMember(Name = "lname")]
public string LastName
{
get;
set;
}
[DataMember(Name = "firstname")]
public string FirstName
{
get;
set;
}
[DataMember(Name = "city")]
public string City
{
get;
set;
}
}

[DataContract()]
public class AddressCollection
{

[DataMember(Name = "houseaddress")]
public virtual List<HAdddress> HAdddress{get; set;}

[DataMember(Name = "officeaddress")]
public virtual List<OAdddress> OAdddress { get; set; }

}

[DataContract]
public class HAdddress
{
[DataMember(Name = "id")]
public System.Guid Id
{
get;
set;
}

[DataMember(Name = "data")]
public virtual HAddressData Data
{
get;
set;
}
}

[DataContract]
public class OAdddress
{
[DataMember(Name = "id")]
public System.Guid Id
{
get;
set;
}

[DataMember(Name = "data")]
public virtual OAddressData Data
{
get;
set;
}

[DataMember(Name = "collections")]
public virtual SeAdddress Collection { get; set; }
}

[DataContract]
public class HAddressData
{
[DataMember(Name = "city")]
public string City { get; set; }
}

[DataContract]
public class OAddressData
{

[DataMember(Name = "city")]
public string City { get; set; }
}

[DataContract]
public class SeAdddress
{
[DataMember(Name = "houseaddress")]
public virtual List<HAdddress> SECAdddress { get; set; }
}

[DataContract]
public class SeAdddress2
{
[DataMember(Name = "id")]
public System.Guid Id
{
get;
set;
}

[DataMember(Name = "data")]
public virtual BaseAddress Data
{
get;
set;
}
}
[DataContract]
public class BaseModel
{
}

//-------------------------------------------------------------------------
object to serialize
//-------------------------------------------------------------------------
var aModel = new AddressModel
{
Id = Guid.NewGuid(),
Data = new BaseAddress() {FirstName = "RamaNaresh", LastName = "Talluri", City = "Atlanta"},
Collections = new AddressCollection()
{
HAdddress = new List<HAdddress>()
{
new HAdddress() {Id = Guid.NewGuid(), Data = new HAddressData() {City = "CA_Toronto"}}
},
OAdddress = new List<OAdddress>()
{
new OAdddress()
{
Id = Guid.NewGuid(),
Data = new OAddressData() {City = "US_Alpharetta"},
Collection = new SeAdddress()
{
SECAdddress =
new List<HAdddress>()
{
new HAdddress()
{
Id = Guid.NewGuid(),
Data = new HAddressData() {City = "CA_Downtown"}
}
}
}
}
}
}
};

jsScope.ExcludePropertyReferences= new []{"Officeaddress.houseaddress.city"};

Thanks

Currently OrmLite's Sqlite adapter supports creation of foreign key constraints when using the ForeignKey attribute on your data classes. However the foreign keys aren't actually enforced at the database by default (for 'compatibility reasons').

I don't know when Sqlite added the feature, but it will check constraints if you send a pragma at the start of each connection:

http://www.sqlite.org/pragma.html#pragma_foreign_keys

I've tested a simple workaround by sending the pragma as a SQL statement in my service methods), and the constraints are enforced as expected. Cascade deletes work as expected too.

However this isn't optimal if you want your service code to be db-agnostic (it's also a bit inefficient if sent as a separate db request, rather than pre-pended to the first request). It would be great to have this enabled at the dialect level so that developers can use db-agnostic code and patterns related to constraint checks and foreign key delete and update operations, regardless whether they are using Sqlite or the other databases that support foreign keys.

My use-case is serializing compound DTO objects before sending them over the wire. There is no escaping the possibility that multiple references may exist. I can try to hack a solution that maintains references before/after serialization, but I really think this should be included in the serialization process as an option if at all possible.

There is already an older post on Stack Overflow about this, and I think (hope? ;) others would want the functionality as well.

http://stackoverflow.com/questions/11644905/serialize-deserialize-complex-type-to-json-with-object-references-and-dictionari)

I didn't want to bump that, so I'll add my comments here:

Currently, PCLs are significantly growing in popularity, as cross-platform development (Interoperability and mobility of objects) becomes increasingly important. Because of this trend, more complex object serialization because more important.

In my particular use-case, I have a transport object that contains some code inside of it to move among logical nodes (intra-process, inter-process, client-server, etc.). This is largely possible due to the shift toward PCLs, and I think I won't be alone in this kind of structure.

I would use BinaryFormatter if at all possible, but it isn't available in PCLs. Json.NET has problems with PCL implementations, and other serialization implementations I've found don't have the active development that Service Stack does - that's why I bought a license for the serializer in the first place. Active and good!

I know you have a ton of other features on the boil, but I think maintaining references in any of your serializers (not necessarily Json) would be a huge success in moving toward the PCL world. That's my three cents.