I am looking way by which I can instantiate Z3 context with Model as input. Instead of feeding my 100+ assertions every time I create context, can I export Model and then import?
Related
I have a request model. A request has one classification. What I want to set up is to store a bunch of form fields in the DB. Their types, names etc. Different classifications will have different form fields for the user to fill out on a request form. So ultimately User creates new request with classification C, and they are presented with a form with the appropriate fields for classification C.
I would like the values stored in a table with the request. My question is how should this be modeled?
Request has one classification.
Classification has_many requests.
I'm just not sure what to do with the dynamic form fields. I would like to be able to create the fields and attach them to the classification. So if first name, last name are fields needed I wouldn't have to create them for every classification. Just create them once and set associate them with a classification through a join table.
Looking for advice on how to model this out and be able to easily reference them from a request.
Thanks! Any info or thoughts are appreciated.
I would say that you should first try to model it according the relational model as far as possible.
# beware of potential conflicts with this name as it clashes with core method in controllers
class Request < ApplicationRecord
has_many :classifications
end
class Classification < ApplicationRecord
belongs_to :request
end
Model everything you know you can normalize. It's usually more then you think.
Dealing with data that doesn't adhere to a fixed schema can then be dealt with a few ways:
Just define all the fields and live with a few nulls here and there.
The Entity–attribute–value (EAV) pattern. This classic approach consists of a separate table where each row represents a value for a classification eg rails g model ClassificationAttribute classification:references attr_name attr_value. This is largely made obsolete by JSON data types.
A JSON/JSONB column. This additional column would be used to shove any unstructured data that cannot be normalized.
Serialized data columns. This also made obsolete by JSON/JSONB.
All of these can be combined with the Single Table Inheritance pattern.
If classification can be broken down into a limited number of variants you could consider Multiple Table Inheritance where you store the base data in the classification table and then use separate tables for the more specific data. Rails delegated_type feature can be used for this.
Your question is really confused and it is hard to understand what you are trying to achieve. But a few remarks:
You say "Request has one classification. Classification has_many requests" But if Request has one classification. Then classification should belongs to request. This way The Classification model holds a field called request_id (foreign key) that will help ActiveRecord link the two models together. (The child model is the one holding a foreign key)
If each is the parent of the other (has_one or has_many), then where is the foreign key ?
dynamic fields is not something possible. Your databse if hard coded: each field is declared in the relational database and Rails ActiveRecord's allows to access it easily and validate it. There is indeed a solution: have one of the model holds a JSON or JSONB field. And the value instead of being of the common types: string, text, integer.. be of JSON type and holds a value that is converted to a hash by Rails :
{
first_name: "Arthur",
last_name: "Smith",
age: "23"
}
This is pretty convenient for shopping carts as you can save an actual list of items rather than an association. Having an association would need to version your items changes (when the price of an item changes for example) which need some good engineering.
The question is : is it what you really want to do ? Because this is an option that doesn't fit all apps or uses.
Also you say the request depends on the classification. I have mentionned the problem of the foreign key above. But it seems weird that one of your record behavior is set by a direct relationship relationship. Who creates the classification ? Is it one of the app models such as the User ? an Admin ? or is it seeded by the app creator (then Classification is a standalone model) ? In this case the classification preexists the request the Request and maybe a has_and_belongs_to_many association (a join table ) would fit better...
Maybe give us a clearer view of what you want to achieve with real life examples so we can help further
I am using spacy to train my own NER model. In addition to entities trained by spacy basic 'en_core_web_sm' model (ORG, PERSON, DATE, etc), I want to add my own entities. I trained my model with 'en_core_web_sm' as my base model, but then the model can only detect my own custom entities only, not the basic entities. Is there any way to do this? Thanks.
You can definitely do this with spaCy, cf the docs and also check Matt's blogpost around the problem of "catastrophic forgetting" (when your model "forgets" about the old types it knew before, which you obviously want to avoid).
I have a User model that has an introduced_by attribute. Based on that attributes value, I calculate my commission differently. What would be the best, most flexible way of doing this?
Should I do a switch, or maybe put everything in a flat file? Also, should I create a Commission model?
It's a very broad question, as there is no code and no example. However, it seems to be the perfect case of a Strategy design pattern.
What I would do, is to create a class that represents the strategy for every specific range of attribute values.
E.g
PersonalCommission
CompanyCommission
HighValueCommission
DefaultCommission
Each class has a single method, let's say calculate that you can call passing an instance of the object and that returns the value of the commission.
Wherever you need to perform the calculation, just initialize a new Commission strategy object based on the User attribute and call calculate on it.
You don't even have to use a switch, as you can initialize the class dynamically.
strategy = "#{user.introduced_by}Commission".constantize
strategy.new.compute(whatever)
Of course, that's just a very simple example you'll have to adapt to your needs.
My question has to do with data modeling.
We have a Score-model which links to both a Division model and a Element model. Between the Division and the Element model a habtm-relation exists. The score has to be evaluated against an attribute of the Element model (criterium attribute).
Now we want to introduce the concept of "Problems". A problem is each score which does not pass the criterium. (additional info: Multiple scores will be recorded over time, different types of scores exist. Filters on score_types and date ranges are desired)
What is the best way to model the Problem concept?
Just calculate the problems in the controller each time the view of the problems is requested
Introduce a Problems-model (which does not really contain any new information from the Score and Element info
Create a tableless Model like ActiveModel.
None of the above, as it is a newbie question and you should do it like so and so ... (fill in the blanks)
Any help would be much appreciated.
Without knowing what your codebase looks like and assuming the Problem model would only be storing the id of an associated Score, I'm going to suggest using a scope on your Score model. You can create the ARel query (or queries) to get the desired Scores without adding too much more code. Check the Rails Guide on Active Record Querying - Scopes section for more info.
If you need the Problem model to do anything that the Score can't do, I'd consider creating an actual model (persisted or not is another decision).
I'm not sure if this question is non-sense or not, please tell me if so. I am wondering do I create my models like one per each table in my database, or do you do one per controller? Is there something I am missing here?
From what I read the Model is suppose to be a representation of the real business objects, so would I just want to make it one big model or divide them out based on things in the app? based on real user/client perception of the data?
Thanks for your advice.
There's nothing wrong with controllers sharing models. But trying to serve every controller with the same model doesn't make sense.
Models and controllers really are't related, nor should they be. Models also aren't directly related to how data is stored in your application.
Models encapsulate data. Their design should be dictated by the data they are encapsulating. The demands of the system dictate what models you'll need and what data they must hold.
Don't try to overthink it. For a given request, determine what you need to show in your view and how it will be displayed. Determine what an appropriate model would look like for this scenario. If one already exists, use it. If not, create a new model. Save the overengineering later when you know what your needs are and can find commonalities between models.
Models can also contain other models, that's fine. Think of a model for a sales report. You would have a model for the report which would contain not only a report name, a total, but also a collection of other models which make up the report's line items.
It depends on what you mean by "Model". If by model you mean the business rule layer of your application, then there is no relationship in terms of numbers. One model of that type is used for any amount of views you need to build.
Personally, however, I would not bind any view to any model, but create an intermediary layer called a ViewModel that essentially taylors the data from your model to fit a particular view. In that case, the relationship is one-to-one. This is essentially how Presenter patterns work. Every view is strongly typed to it's own ViewModel that is populated from the Model layer.
Models do not necessarily have a literal coorespondence with the database either. How you store data your model is different from how your "Model" uses that data.