I have a product class that is stored in Cosmos DB together with its variants.
[DataContract]
public class Product
{
[DataMember]
public virtual string Name { get; set; }
[DataMember]
public virtual IList<Variant> Variants { get; set; }
}
[DataContract]
public class Variant
{
[DataMember]
public virtual string Name { get; set; }
}
I would like to query a projection of the variants that includes the Product.
[DataContract]
public class VariantProjection
{
[DataMember]
public virtual Product Product { get; set; }
[DataMember]
public virtual string Name { get; set; }
}
I'm using the DocumentDB Linq api, but if it's not possible with this api any other API would be ok.
Sounds like you are looking for JOINs and Projections (might want to try the Cosmos DB Query Playground, it has scenarios for both).
It would be great to have a simple dataset to test but I believe something like this might help:
SELECT p as product, variant.name
FROM p
JOIN variant IN p.variants
Keep in mind though that you are retrieving the entire Product for each variant. That's what you are trying to achieve in your C# code.
Related
I'm looking for a way to map several POCO objects into single table in the ServiceStack.
Is it possible to do this in a clean way, without "hacking" table creation process?
As a general rule, In OrmLite: 1 Class = 1 Table.
But I'm not clear what you mean my "map several POCO objects into single table", it sounds like using Auto Mapping to populate a table with multiple POCO instances, e.g:
var row = db.SingleById<Table>(id);
row.PopulateWithNonDefaultValues(instance1);
row.PopulateWithNonDefaultValues(instance2);
db.Update(row);
If you need to maintain a single table and have other "sub" classes that maintain different table in the universal table you can use [Alias] so all Update/Select/Insert's reference the same table, e.g:
public class Poco
{
public int Id { get; set; }
public string Name { get; set; }
public int Age { get; set; }
}
[Alias(nameof(Poco))]
public class PocoName
{
public int Id { get; set; }
public string Name { get; set; }
}
[Alias(nameof(Poco))]
public class PocoAge
{
public int Id { get; set; }
public int Age { get; set; }
}
Although I don't really see the benefit over having a single table that you use AutoMapping to map your other classes to before using that in OrmLite.
I am new to using DTOs.
I have two domain classes:
Category
Product
as follows
public class Category
{
// Properties
public int Id { get; set; }
public string Name { get; set; }
// Navigation properties
public virtual Category ParentCategory { get; set; }
// Foreign key
public int? ParentCategoryId { get; set; }
// Collections
public virtual ICollection<Product> Products { get; set; }
public virtual ICollection<Category> Subcategories { get; set; }
}
public class Product
{
// Properties
public int Id { get; set; }
public string Name { get; set; }
// Navigation property
public virtual Category Category { get; set; }
// Foreign key
public int CategoryId { get; set; }
}
I want to use Automapper.
I am not sure how to design DTOs for the above aggregate (graph).
Should CategoryDTO have a collection of type ProductDTO or a collection of type Product?
Should ProductDTO have a CategoryDTO as navigation property or a Category or just an Id to the Category?
Can anyone suggest the code for DTOs?
How should this structure be flattened (if it should) and mapped to domain classes?
Many thanks in advance.
I design my DTOs to be only the data used for a specific controller action for MVC. Typically this means if I have a CategoryController, then I have a CategoryIndexModel, CategoryDetailsModel, CategoryEditModel etc etc. Only include the information you want on that screen. I flatten as much as I can, I don't create child DTOs unless I have a Partial or collection.
I am trying to serialize an object to Azure Mobile Services.
The object contains an array of a second object which should also be serialized.
[DataContract()]
class ObjectA
{
[DataMember(Name= "id")]
public int Id { get; set; }
[DataMember(Name = "info")]
public string info{ get; set; }
[DataMember(Name = "collectionOfB")]
public ObjectB[] myArrayOfB{ get; set; }
}
[DataContract()]
class ObjectB
{
[DataMember(Name= "id")]
public int Id { get; set; }
[DataMember(Name = "info")]
public string info{ get; set; }
}
I have loaded both table's properly and can insert an individual item into each of the tables.
However when I call the InsertAsync method on the table for objectA I receive an error
Cannot serialize member 'myArrayOfB' of type 'namespace.ObjectB[]' declared on type 'ObjectA'
Any idea's on what I need to do to fix this?
Mobile Services doesn't support serialization of arrays. There are two good posts here that show how you might support this:
http://blogs.msdn.com/b/carlosfigueira/archive/2012/08/30/supporting-arbitrary-types-in-azure-mobile-services-managed-client-simple-types.aspx
http://blogs.msdn.com/b/carlosfigueira/archive/2012/09/11/supporting-complex-types-in-azure-mobile-services-clients-implementing-1-n-table-relationships.aspx
I have a list of Users and Orders.
public class UserRecord
{
public virtual int UserId { get; set; }
public virtual string Name { get; set; }
}
public class OrderRecord
{
public virtual int UserId { get; set; }
public virtual int OrderId { get; set; }
}
I have two repositories - IRepository and IRepository. How can I join the two and fetch the result, like this?
SELECT UserRecord.UserId, Name, OrderId
FROM UserRecord, OrderRecord
WHERE UserRecord.UserId = OrderRecord.UserId
Thanks.
Use the HQL API that is on ContentManager instead. Repository is for simple CRUD operations on a single table.
I see these types of model is many samples online.
public class User
{
public long Id { get; set; }
public string Name{ get; set; }
public virtual ICollection<Product> Products { get; set; }
}
Is it considered a good practice to instantiate a collection in the constructor like the code below? If so what are the reasons? How about objects in the model?
public class User
{
public User()
{
Products = new List<Product>();
}
public long Id { get; set; }
public string Name{ get; set; }
public virtual ICollection<Product> Products { get; set; }
}
Well, I would say it depends on the situation, but Products in this case would be filled from the database, via a repository, so most probably ORM of some sort, so no initialization to new List would be needed in the constructor. The meaning of null for Products is indicative that the list isn't loaded yet. On the other hand, let's say that your object must have this collection initialized. For simple objects DDD says constructors are perfectly fine to to these things, but in case of complex objects, move the construction to the Factory.