The model ids are unique in all clases.
I want to know how to use "get_by_id()" without know the model class name.
For example, in
MyModel.get_by_id(42)
need to use "MyModel" class
and in this other way
ndb.Key(MyModel, id).get()
need the class name too.
I think that could be posible something without the class name. I am rigth?
Thanks for your answers.
No, you can't. First, the auto-assigned IDs are not unique across models. Second, entities have a "key" that is composed of one or more (model, ID) pairs -- the model (== class name) is an essential part of the key.
You may be confused by queries. It is possible (though not recommended) to have a query for "all entities", i.e. without specifying the model. But this will obviously not scale.
Related
I need to implement EAV and I'm hitched on polymorphic relation.
For example models are:
ProductPage.
Attribute.
AttrValDecimal.
AttrValBool.
AttrValOtherType
How to create relations attribute-value and product-value correctly?
Every attribute can be one of few types: decimal, boolean, item from varchar list, few items from varchar list, etc...
so relations with value must be polymorphic.
I have already read this part of documentation
https://docs.silverstripe.org/en/3/developer_guides/model/relations/#polymorphic-has-one
but still cant sort out how to implement EAV.
I'd to it the other way: have a has_one relation from the value objects back to attribute. Then add a Type enum to Attribute.
Your value tables will technically allow multiple values per attribute, but perhaps that's a feature you need?
The other, in retrospect probably better, way to handle this wood be to make BooleanAttribute a subclass of Attribute and let SilverStripe's multi-table inheritance do Bebe work for you.
You'll have to write your getters for value manually, and figure out which table to join to, but polymorphic has one isn't going to be any magic fix there - it's pretty simple.
Bigger picture I'd also challenge whether EAV is really what you need - it's going to create some really big queries and not be very good for searching. If searching doesn't matter and all need is flexible properties, maybe a JSON payload would be better?
I have Order and OrderType classes in my sale module, that OrderType class uses for some categorization goals and applying some business rules on Orders. each class has its own table.
I want to apply DDD techniques on my project.
So, I think that the Order is an Aggregation root, but what about OrderType?
Is it also contained in Order aggregation or is it a Value object?
I think it will be a value object.
Am I correct?
There is a common question "Entity vs Value Object".
what about OrderType? Is it also contained in Order aggregation or is
it a Value object? I think it will be a value object. Am I correct?
I would say that OrderType is an entity but it depends an your domain.
The difference between Value Object and Entity is simple:
Value objects are considered the same when all their properties are equal.
When you care only about the attributes and logic of an element of the
model, classify it as a value object. Make it express the meaning of
the attributes it conveys and give it related functionality. Treat the
value object as immutable.
Entities are considered the same when they have the same identity.
When an object is distinguished by its identity, rather than its
attributes, make this primary to its definition in the model. Keep the
class definition simple and focused on life cycle continuity and
identity.
There is a simple “litmus test” for Entities:
If two instances of the same object have different attribute values,
but same identity value, are they the same entity?
As always "it depends..."
From your description it seems that it should be a Value object or, as Eric Evans means, Readonly entity without identity.
Should OrderType be a separate entity (can be sent to another objects) or it is small part of Order object?
Should OrderType has identity and be unique object even with same fields (Code, Title)?
Yes -> Entity with ID; No -> Value object
It's possible you may not even need a class to model OrderType. An enum with an attribute may be sufficient if your programming language supports it, e.g.
public enum OrderType {
[Code("ABC123")]
OneTime = 0,
[Code("XYZ456")]
Repeating = 1
}
In my Rails project, I have the two similar models SafetyTest and TeamDue. Their fields are exactly the same, and they differ only in name. Each instance belongs_to a Student.
I would like to add the ability to create new models that follow the structure of the two above. So maybe I'd like to add MedicalForm. I don't want to do this over a CLI as a developer, but provide an interface in the view so that administrators can add their own.
Let's say that SafetyTest, TeamDue, and MedicalForm can all be described with the name SeasonalRequirement. What would be the best and most maintainable way to implement my idea?
I'm not experienced in Rails, but an idea that I had was to incorporate the models above into one comprehensive model called SeasonalRequirement, and just add a type column for every type. The problem with this: How would users create a new type of seasonal requirement (such as MedicalForm)? And how would I even determine what types of seasonal requirements there are when I'm trying to display a separate section for every one?
I would consider a polymorphic or STI relationship for this.
See more details at: http://code.alexreisner.com/articles/single-table-inheritance-in-rails.html
I would use STI to model this.
Not used RoR much, bu it seems like a bad idea to have the users change the structure of the database.
What might work is something like this:
additional_student_columns
--------------------------
id
name
and add another table:
additional_student_values
--------------------------
student_id
column_id
value (string)
The disadvantage of this is that it can use just string values
My application is CoreData based but they may be a common theory for all relational databases:
I have a Output-Input to-many relationship in my model. There are potentially an unlimited number of links under this relationship for each entity. What is the best way to identify a specific input or output?
The only way I have achieved this so far is to place an intermediate entity in the relationship that can hold an output and input name. Then an entity can cycle through its inputs/outputs to find the right relationship when required. Is there a better way?
Effectively I am trying to provide a generic entity that can have any number of relationships with other generic entity.
Apologies if my description isn't the clearest.
Edit in response to the answer below:
Firstly thank you for your response. I certainly have a two-way too-many relationship in mind. But if a widget has 2 other widgets linked to its Inputs relationship what is the best way of determining which input is supplying, say, 'Age' or 'Years Service' when both may have this property but I'm only interested in a specific value from each?
I'm as confused as Joshua - which tells me that it may be that you haven't got a clear picture of what you're trying to achieve or that it is somewhat complex (both?).
My best guess is that you have something like:
Entity Widget
Attributes:
identifier
Relationships
outputWidgets <<->> Widget
inputWidgets <<->> Widget
(where as per standard a ->> is a to-many relationship and <<->> is a to-many relationship with a to-many reverse relationship).
So each widget will be storing the set of widgets that it has as outputs and the set of widgets it has as inputs.
Thus a specific widget maintains a set of inputWidgets and outputWidgets. Each of these relationships is also reversed so you can - for any of the widgets in the input or output - see that your widget is in their list of inputs or outputs.
This is bloody ugly though.
I think your question is how to achieve the above while labelling a relationship. You mention you want to have a string identifier (unique?) for each relationship.
You could do this via:
Where you create a new widgetNamedRelationship for each double sided relationship. Note that I'm assuming that every relationship is double sided.
Then for each widget you have a set of named inputs and named outputs. This also allows for widgets to be attached to themselves but only of there are separate input and output busses.
So then for your example "age" in your implementation class for Widget instance called aWidget you'd have something like:
NSPredicate *agePredicate = [NSPredicate predicateWithFormat:#"name='age'"];
NSSet *ageInputs = [aWidget.inputs filteredSetUsingPredicate:agePredicate];
Have I understood the question?
There really is no better way if you want to be able to take full advantage of the conveniences of fast and efficient in-store querying. It's unclear what you're asking in your additional comments, which I suppose is why you haven't gotten any answers yet.
Keep in mind Core Data supports many-to-many relationships without a "join table."
If Widget has many Inputs or Outputs (which I suspect could be the same entity), then a many-to-many, two-way relationship (a relationship with an inverse, in Core Data parlance) between Widget and Input is all you need. Then all you need to do is see if your Input instance is in the Widget instance's -inputs or if a Widget instance is in the Input instance's -widgets.
Is that what you were looking for? If not, please try to clarify your question (by editing it, not by appending comments :-)).
I am trying to figure out the best way to model a set of "classes" in my system. Note that I'm not talking about OO classes, but classes of responses (in a survey). So the model goes like this:
A Class can be defined with three different types of data:
A Class of Coded Responses (where a coded responses consists of a string label and an integer value)
A Class of Numeric Responses (defined as a set of intervals where each interval ranges from a min to a max value)
A Class of String Responses (defined as a set of regular expression patterns)
Right now we have: Class table (to define unique classes) and a ClassCoded, ClassNumeric and ClassString table (all with a ClassID as a foreign key to Class table).
My problem is that right now a Class could technically be both Coded and Numeric by this system. Is there any way to define the set of tables to be able to handle this situation??
There are two main ways to handle subtypes, either with sparse columns by adding columns for every possible property (preferrably with check constraints to make sure only one type has values) or to create a table for the supertype and then three tables for the sub-types, each with foreign keys back to the supertype table. Then add a check constraint to ensure that only one of the three possible type columns is not null.
Personally I decide which of the two implementations to use based on how similar the subtypes are. If 90% of the columns are shared I use the sparse columns approach, if very little information is shared I use the multiple tables approach.
Relational databases don't handle this elegantly. Simplest way is to define columns for all different types of data, and only fill the appropriate ones.
I don't understand what the issue is. This is just mixin inheritance. Why can't a Class just have an entry each both ClassCoded and ClassNumeric?
The enforcement of business rules isn't going to be done in the DB anyways, so you can easily enforce these constraints in the business layer code with special rules for Classes that have entries in both these tables.