I have two classes:
[DynamoDBTable("Book")]
public class Book
{
[DynamoDBHashKey]
public string Identifier { get; set; }
public List<Section> Sections { get; set; }
}
[DynamoDBTable("Section")]
public class Section
{
[DynamoDBHashKey]
public string Identifier { get; set; }
public string Title { get; set; }
}
How do I perform an operation in DynamoDB to check if the value exists inside Book -> Sections
If there is an Identifier in the list of sections.
The purpose of my operation is to alert the user if he tries to delete a section that has a linked book.
A serious check operation before doing the line below:
_context.DeleteAsync<Section>(identifier).GetAwaiter();
I tried to use the scan condition, but without success.
I also tried to perform a query mapping operation, but I think I did something wrong.
Does the Sections List in the Book class have to be a List<Section>?
If it was just List<string> SectionIdentifiers, then you could just use SectionIdentifiers.Contains(someID). In this case you've reduced what you're looking up to string literals so you don't have to worry about your custom Section class.
Related
I have to tables created theme by Entity Framework for example:
Book Table:
public class Book
{
public int Id { get; set; }
public string Title { get; set; }
public int Book_Type_Id { get; set; }
}
Book_Type Table:
public Book_Type
{
public int Id { get; set; }
public string Title { get; set; }
}
I will store some limited values for example Novel and education and ... in Book_Type table But in this way searching string can has spelling error. I think it's cannot be correct and may be exist a way for example use a predefined list and store specific Book type value as string.
what is your opinion?
You maybe looking for an Enum. A value type data type, where you decalre all distinct possible value. In order to have those name constant and easly refered to.
Ef does support the enum. And it's pretty strait forward. Declare then Use it.
Here is a msdn article and video about
MSDN: Enum Support - Code First
I have a couple of classes:
public class MyGoalsModel
{
[Key]
public string Name { get; set; }
/*Some local bools*/
public List<MyGoalString> myGoals { get; set; }
}
public class MyGoalString
{
public int MyGoalStringID { get; set; }
public string GoalString { get; set; }
public bool Selected { get; set; }
}
I can populate them correctly, and the code (EF?) generates the necessary hidden foreign keys to link them (all ok in SQL) and recover the information for MyGoalsModel, but the List is always null.
I use the following to get the entry I want:
MyGoalsModel goals = db.MyGoals.Find(Name);
but when I investigate the code goals.MyGoals is always null.
Am I missing something, is there a better way to recover the information with the lists present?
Add the keyword virtual so EF can create a proxy for your List and lazy load the data when needed.
Edit: Or as stated in the accepted answer in this question.
I am using mongodb C# driver and trying to add "Goal" Entity in the "List", contained in Client class, but mongodb always returns an empty objectId og Goal.
Client.cs
public class Client
{
public string UserName { get; set; }
[BsonId]
public ObjectId ClientId { get; set; }
[BsonIgnore]
public string ClientIdString
{
get
{
return this.ClientId.ToString();
}
}
[BsonRequired]
public string ClientName { get; set; }
public string EmailAddress { get; set; }
public string CompanyName { get; set; }
public List<Goal> Goals { get; set; }
}
Goal.cs
public class Goal
{
public ObjectId GoalId { get; set; }
[BsonRequired]
public string Title { get; set; }
public string Description { get; set; }
[BsonDefaultValue(State.NotStarted)]
public State GoalState { get; set; }
[BsonIgnore]
public string StateString
{
get
{
return this.GoalState.ToString();
}
}
}
and i am trying to add Goal to client with following code:
IMongoQuery query = Query<Client>.EQ(eq => eq.ClientId, id);
IMongoUpdate update = Update<Client>.Push<Goal>(push => push.Goals, goal);
WriteConcernResult result = this.ClientCollection.Update(query, update);
But every time mongodb returns an empty objectId of newly added Goal in the List in client.
Kindly guide me what i am doing wrong?
Thanks in advance. :)
Kindly guide me what i am doing wrong?
Nothing really, but you're expecting the wrong behavior.
Embedded documents don't have an _id. Of course, you can force mongodb to create a field that happens to have that name, but unlike the root _id, such a field has no special semantics and there's no default index. The lack of these special semantics is also the reason why the driver doesn't bother generating a value for the field for you.
Generally speaking, having a unique index in an embedded document is often a sign of a malformed data structure. Make sure such an id is strictly required. If the id must be globally unique, it appears the embedded document might also make sense or be relevant if it had another parent, which indicates that it should be a first-level citizen, i.e. have a collection of its own.
Remember that this also a question of ownership - what happens with concurrent writes? Of course, you can go to great lengths and only use atomic modifiers to allow different writes to one document, but that is unnecessarily complicated IMHO.
I'm trying to whip up a POC of a system which allows you to create and modify enumerations that are eventually used in an application using the front-end. Something like dynamic enums.
For example, in a hypothetical bug tracker application, we can have a status enum that could have values of open,accepted and closed. All these enums (and their corresponding values) can be changed in real-time via the UI, so it is possible for an admin to come up with a new reassigned value for example (through an Admin page, most probably) somewhere down the application's lifetime. It would also be possible to create new enums as well, which in turn have their own values (for example, a complexity enum).
The way I'm currently envisioning it is that I'll have an Enumeration class, which has a 1:* referential with an EnumerationValue class.
public class Enumeration {
public string Name { get; set; }
public ICollection<EnumerationValue> Values { get; set; }
}
public class EnumerationValue {
public string Name { get; set; }
public string Description { get; set; }
}
That's the easy part. When I get to creating the entity that actually uses these dynamic enums, I hit a snag.
Let's say I'm creating the BugRecord entity, which consequently has a Status property. Following the logic above, I'd have to write it along the lines of:
public class BugRecord {
public EnumerationValue Status { get; set; }
}
But given that I could have lots of different Enumerations (and EnumerationValues), is there a way for me to restrict BugRecord.Status values to only EnumerationValues in the status Enumeration? If not how would you recommend I tackle a problem of this kind?
Create a third Entity/JoinTable EnumerationChoice and use it to map the BugRecord to the EnumerationValue
public class EnumerationChoice {
public Enumeration EnumerationCategory { get; set; }
public EnumerationValue Value { get; set; }
}
BugRecord now becomes:
public class BugRecord {
public EnumerationChoice BugType { get; set; }
public EnumerationChoice Status { get; set; }
}
The data would now look like:
BugRecord:
EnumerationChoice:
-BugType
-BugTypeValue1
EnumerationChoice:
-Status
-Open
This way, when you try to populate the EnumerationChoice, you can reference the EnumerationCategory to get the valid EnumerationValues assigned to it.
I have a set of contact infos that I will be displaying in an ASP.NET MVC page
They will either have an email address or information to contact
should I have this setup
public class Contact
{
public int ID { get; set; }
public string Name { get; set; }
public string Email { get; set; }
public string Explanation { get; set; }
}
where email address is shown when explanation is null
or
public class Contact
{
public int ID { get; set; }
public string Name { get; set; }
public string DisplayInfo { get; set; }
public int DisplayInfoType { get; set; }
}
where the display info type determines how I will display the info.
First approach: it's more expressive!
The domain model is more expressive in the first example; it speaks for itself what the data means.
That you need to have one of the two filled is a business rule which you don't need to express in the properties of your entities.
DisplayInfo or for that matter any similar display logic should be incorporated in the Views. The business logic is not responsible for what part of the domain has to be shown to the user on the view. This should be taken care at the view-level.
The first setup is better. It expresses what the fields do more effectively. It delays the execution of UI logic until the appropriate layer.
Also note that your Email may be empty as well as null. Additionally, you may get more use out of a field name such as ContactInstructions instead of Explanation (explanation of what?).