I'm acutually trying to make a one-to-many relationship between the auto generated table "jhi_user_authority" and my own table called socialMediaFilter.
My situation is the following:
On the one side I have users, these are saved in the table "jhi_user" these users have roles and the roles for themselves are saved in a table called "jhi_authority". Between users and roles is a many-to-many relation, that means that many users can have many roles. These relationships are saved in a join-table called "jhi_user_authority". All these 3 tables are auto-generated by Jhipster when I created the project.
In my project I need to add some filters for filtering data from social media networks, twitter, fb and so on. A filter belongs to a role and a role can have many filters. So between these two tables is a one-to-many relationship and I'm struggling implementing this in my project.
I cannot access these auto-generated tables with the jhipster:entity generator. When I'm using for example yo jhipster:entity authority jhipster tries to generate a new entity. And as far as I know - these auto-generated tables are not meant to be accessed by the entity-generator. So when I want to edit them I need to edit them manually, so I can not follow the instructions in the tutorial.
Is there maybe someone who can pushes me to right direction? :D
thanks,
Alex
EDIT:
okay...after thinking for a while i figured out that i need to do it different
the relationships i need to implement should be like this uml
but i still have problems realizing it
Good morning, you have to do an n-m relation with the "Authority" class, in which you must specify that the relationship table is "jhi_user_authority"
Related
I'm creating a backend application and I'm trying to implement the Domain Driven Design.
However, I had a question regarding my data structure that I intend to clarify.
Database Structure
Users
Id (PK 🔑)
First Name
Last Name
Email
Password
Customers Profile
User Id (PK / FK 🔑)
Height
Weight
Personal Trainers Profile
User Id (PK / FK 🔑)
Specialties
Taking into account the database represented above, I have some doubts on how to structure the Controllers, Services and Repositories of my application.
Let's imagine, that I want to update a Customer Profile and their User:
I call the Customer Controller (update endpoint)
The Customer Controller calls the Customer Service (update customer method)
The Customer Service calls the Customer Repository to update the Customer Profile
And to update their respective User on Users table?
Should the Customer Service call an update method from the User Service?
Or should the Customer Service call the User Repository directly?
I'm very confused, not knowing if it's correct, services know about other services, or services know repositories that theoretically belong to other services.
I will be very gratefully if someone could help me clarifying my doubts 🙂
I think the Database structure can be improved.
Rather than naming the table as Customer Profile and Personal Trainer Profile, name it as Customers and Personal Trainers.
As A Customer is a User
&
A Personal Trainer is a user
Updated Database Structure
Users
Id (PK 🔑)
First Name
Last Name
Email
Password
Customers
Id (PK 🔑)
User Id (FK 🔑)
Height
Weight
Personal Trainers
Id (PK 🔑)
User Id (FK 🔑)
Specialties
The Aggregate Roots are Customers & PersonalTrainers.
Now the Controllers and Services will be for Customers & personal trainers.
And any update to fields for users table for customers will be done via Customer Controller.
The class definition
public class Customers extends Users
&
public class PersonalTrainers extends Users
Sorry if I'll be a bit 'crude', but in your approach there's no real clue about DDD. I mean: Controllers, Services and Repositories are the 'the facto' way to develop an application with Spring. But this is not really DDD. To implement it with DDD you have to forget the database, focus on the entities of the domain, identify their functionalities and start to think how to translate this into code.
With this preface, I can say you that also within this 'the facto' approach is possible to adopt a DDD, at the price to rethink all the process that produces the code.
Hence, in your model, I would do something like this:
identify the entities of the domain that you want to model (here you have to find the root entities, aggregates and value objects -link 1, link 2);
given that the DDD is an object oriented approach, once you've identified your entities (and this is not so simple as it looks, believe me), you need to identify the functions that each entity offers. So, for example, for the PersonalTrainer entity, one possible function could be acceptTrainee(Course course, Person trainee), that add a new Person to a Course (remember, it's a sample, I have no idea about your domain).
Once you know your entities, or at least you start to identify them and some functions, you can think about the code. Here you can choose between several architectures: clean, ports & adapters, onion, 3-Layers architecture (the default and classic approach with Spring: controllers, services and repositories with entities). My personal approach is more or less what is described here.
I would suggest you to search and read a lot about how to do the things. There's no silver bullet, unfortunately: sometimes the domain is really simple and the extra overhead of a DDD and an 'unsual' architecture are totally useless; sometimes the domain is complex and big, hence a DDD approach with a more refined architecture are a much better choice.
Finally, to give you a concrete answer to work on your case, after identifying the entities and their functions I would put the model that you have produced into a domain package. Here I would also define the Repository interfaces, that you use to persist the entities (but you'll implement later). Once you have this, you can develop the services, where you put all the things together using what you have into the domain. I would put this code into an application package (but, remember, it's not a law: if you think is better, place them in a different place, or with a different name - take a look here, I really like this approach). Finally, I would start to implement the code of the infrastructure layer, where all the interfaces defined into the domain and the application layers will be implemented. Here I would put also the Controllers.
Remember: this approach allows only connections in one direction (domain -> application -> infrastructure), but never the opposite.
Finally, if you think about how to manage the domain entities with some ORM frameworks, I would suggest you to read this links: domain vs persistence model; stackoverflow question about this; domain and persistence separated.
Aggregates are independent objects that ensure consistency within the aggregate. A User represents a specific concept and a CustomerProfile another. The CustomerProfile should rather have its own Id (not necessarily UserId). Nothing stops you from modelling it as you have but keeping state changes on the two aggregate separate is going to make your life a lot easier.
That being said, whenever I do find that I have application services that make use of one another in some way I apply the good old "All problems in computer science can be solved by another level of indirection". I take the common bits and make a Task of sorts and use that in each.
I feel like I've progressed a bit far from day 0 in learning node-express + mysql + sequelize, BUT, I'm still confused like if I'm still on the right path.
I'm designing a User role models, one user has only one role model.
Questions are:
do I always have to make one sequelize model file per table?
I read about normalizing database tables, so I'm thinking not making a role_id column in my Users table, and instead make a new table. Is this right?
For instance, I have tables in my scheme design (not sure if it's the correct term, I drew my db design on https://dbdiagram.io/) namely:
Users table
Roles table
UserRoles table
USERS has id(pk), full_name, email.
ROLES has id(pk), description, user_id(foreign key????)
USERROLES has id(pk), user_id, role_id
Yes this will be very useful because:
you'll always be sure where to find a certain model - just find a file with that name in models folder.
you;ll be ale to automatically register all models at once simply by reading all files in a models folder and register them in sequelize
Yes you need a join-table (many-to-many relationship) to link users and roles.
In our Dynamics CRM online custom project - we've the default ACTIVITIES tab in a custom entity named DocProject's form
ACTIVITIES is able to take multiple entries.
Also, there is NOTES tab in the same form
NOTES is also able to take multiple entries.
Okey, this is done by Dynamics CRM guys. So far so good.
In the same form, we also have a DocProjectActivities lookup field for a custom entity DocProjectActivities
This is a lookup field, hence it has got a 1:N relationship.
Clarification: Our problem is not only about Activities. WKT Notes also behaves similarly. We just need some config which will allow us to make multiple entries for one single field
Problem:
How do one makes sure that this custom entity DocProjectActivities allows to make multiple entries as that for ACTIVITIES & NOTES?
In order to have the associated activity grid like the one in the DocProject entity, you need to enable the option Activities when you're creating the entity (this option can't be changed after the entity is created). This option will create the association with the activities entities and allow you to track all the related phone calls, task, etc.
I think that the problem that you're having is that you defined the DocProjectActivities as an activity entity and therefore you can't have this kind of relationship with the other activities entities. I recommend you to take a look to the differences between Entities and Activity Entities.
Do you mean you need multiple docprojectactivities on the form where you have the activities?
You need to create a 1:n relationship between the form and the docprojectactivities and add the subgrid on that form allowing you to create multiple records for the docprojectactivities.
A lookup field is the '1' side of the 1:n relationship and thus the wrong direction.
Go to docprojectactivities, add a new field type relationship towards the entity you are working on.
Save and publish.
Now go back to the form designer of the entity you need the entries on and go to the tab 'insert'.
Click on sub-grid and select only related records docprojectactivities (entity you are working on)
If you want your custom entity to work as an activity entity, you should have selected "Define as an activity entity" when you created it.
You cannot make a normal lookup field to multiple entities (with the exception being the possibility of creating Customer fields that was introduced in 2016.1).
I have a website with an offline datastore (IndexedDb) and I have a couple of entities that can be related to each other by foreign key, lets call them TableA and TableB. While offline I want to create a new TableB and have TableA join to it by a foreign key.
TableA.TableBId
What is the best way to persist this back to the Db once online again and keep the relationships. The tables in the database have an identity column that is used for the Id but this is obviously created in the database not in the front end application. Any suggestions are welcome!
Here is how I managed this.
I created guids in the offline ui end and tacked those onto my entities and included this new guid in the actual server side table. I could then perform look ups on the entity using a combination of the guid and the real identity column.
Sorry if this isn't very clear but its a tricky thing to explain really without seeing what is going on along with diagrams!
Good evening,
I currently have 3 tables on my API at backendless.
**Users** (objectId, email, username, password)
**figures** (objectId, figure_name, figure_cat, figure_image, figure_info)
My figures data has rows kind of like a product.
Basically, I would like to link entries in the figures table to users but i'm not sure the best way to go about it.
I can create relationships of one-to-one and one-to-many but being new to that i'm not sure the best way to go about it.
Any help or advice would be much appreciated :)
does a user have many figures?
Can multiple users share the same Figure?
Assuming that a user has many figures, so you will have a userid column in the figures table (1:M rel between user->figures). I also assume your figure_cat is a relatively static list, so consider a lookup table for that so it has a fkey in the figures table as well. Also depending on the size of images, it may be better to put images in a different table so you can put them in a different file group.
Assuming figures are shared by users, you may need a M:N table in between users and figures that stores the userid, to figureid mapping (sometimes called a "tie table" I think)
What database are you using?
You can create a relationship between the tables either directly in the console or by making an API call where you save an object which references other (related) objects. See the documentation for details: http://backendless.com/documentation/data/js/data_relations.htm