We have a complex, multi system architecture and while we have documentation with diagrams, i want to combine all of the digrams to be at field level, grouped by the objects. With that, the key part will be to select field(s) and object which will then highlight the route the data flows to and from.
Example: updating field "system1.name.string" also updates "system2.firstname.string" and "system6.name.string"
Related
I am not able to figure out that how should I store system related information in Moqui.
For example, if I am using the HiveMind application for a particular organization (ABC Corp), I have to hard code the value while making records for the particular organization. I could not find any suitable entity that will allow me to handle this particular case.
So is there any method by which I can handle this particular case?
For example, when I am creating users and clients in the HiveMind application, there is no record in the database that will specify that the Users are employees of a particular organization.
For clients they are just stored in the Organization entity and no relationship exists that will specify that. I can handle that case by creating a party relationship whenever a new user or client is created.
But I will have to hard code the value of the Party with which I want to create the relationship. Suppose ABC corp is using the HiveMind application, I would have to hard code ABC corp's party Id whenever I create a new user or client. Rather that hard coding this value, it would be more efficient for me to fetch this particular value from the database. Whenever a new Organization wants to use the application, I will just change it in the database and the service code will remain as it is.
This is really an application design question and not an aspect of the framework, but I'll share some thoughts on it.
Business level configuration should generally be done in the database in structures (entities) that are designed for the purpose. Sometimes it general values are needed, but this should be the exception and only rare cases. In Moqui the way to handle user or user group preferences is to use the UserPreference and UserGroupPreference, and for all users use the ALL_USERS group that is standard in Moqui (all users are automatically part of this group). This can be done directly on the entities or using the relevant methods on the UserFacade (ec.user).
That said, from a business and application design perspective for apps based on Mantle (for others reading in, this is the business artifacts project based on Moqui) I wouldn't recommend doing it this way. If you want to support multiple organizations when creating an employee you should have a field on the form to select which organization the employee is part of (and then create the PartyRelationship record as you implied).
In HiveMind there can be multiple vendor organizations with people in different roles associated with them. When creating a project you select the vendor and client organizations for the particular project so we know who to bill from and to, which users are involved with different aspects of the project, etc.
If you do want to support just one vendor organization you may as well hard-code it and not make it visible or selectable anywhere in the application, and make it part of the "seed" data of the app in the more strict sense of the term seed data as data that code depends on directly (i.e. uses "hard-coded", though that term has negative implications that are often unjustified, directly use string values are often quite useful and improve clarity and maintainability).
Lets say I have a table EmailQueue that is used to build out emails to send to users, using several non related processes. The Emails can contain a ever growing number of different 'content items' but for now lets just say we have News, Events, and Offers. Each of these 'content items' are already populated in their own respective tables and will be selectively added to a users email.
Now I have a design decision to make.
1
I could keep with a normalized pattern and create a mapping table for each of the 'content items' that an email can contain.
|EmailId|NewsId| , |EmailId|OfferId| , ...
The main issue I see with this design is that there is a good bit of overhead every time a new 'content type' is integrated to the email system; Both in database and object mapping.
OR
2
I could create 1 mapping table that has a Type reference.
|EmailId|ContentID|ContentType|
Of course the big issue here is that there is no referential integrity. I feel object mapping would be much easier to handle and adding a new object only requires adding a new ContentType row (and of course the required object mapping code).
Is one of these solutions better than the other? Or is there a solution better than both of these that I am unaware of?
I'm leaning towards using method 2, mainly because this project needs to be rapidly developed, but worried I may regret that decision down the road.
Note: We are using subsonic as our data access ORM, which does a decent(not perfect) job of handling object graphs through keyed relations. I will still likely need to map the active record 'content' objects to domain object though.
I've been developing several iOS applications using Core Data and it has been an excellent framework to work with. However, I've encountered an issue whereby we more or less have distributed objects (synced) across multiple platforms. A web/database server backend and mobile devices.
Although it hasn't been a problem until now, the static nature of the data model used by Core Data has me a little stuck. Basically what is being requested is a dynamic forms system whereby forms can be created on a server and propagated to the devices. I'm aware of the technique for performing this with a set number of tables with something like:
Forms table
Fields table
Instance of Forms table
Instance Values table
and just linking everything together. What I'm wondering however is if there is an alternative system to Core Data (something above talking to an SQLite database directly) that will allow for a more dynamic object graph. Even a standard ORM would be good if there are options for modifying the schema at runtime. The main reason I want to go down this route is for performance in the sense that I don't want the instance values table exploding with entries (on the local device or server).
My other option is to have the static schema (object-graph) on the iOS devices but have a conversion layer on the server's side which fetches the correct object, populates the properties and saves it to the correct table. Then when the devices comes to sync, it does the reverse and breaks it down into instances. While this saves the server from having a bloated instance value table, it could still be a problem on the device.
Any suggestions are appreciated.
Using specific tables/entities for forms and fields, and entities for instances of each, is probably what I would recommend. Trying to manipulate the ORM schema on the fly if it's going to be happening frequently doesn't seem like a good idea in general.
However, if the schema is only going to change infrequently, you can probably do it with Core Data. You can programatically create and/or manipulate the NSManagedObjectModel prior to creating a NSManagedObjectContext. You can also create migration logic so data stored in an old model can be preserved when you update the model and need to recreate the context and stores.
These other SO posts may be helpful:
Customize core data model at runtime?
Handling Core Data Model Changes
You need to think carefully about what you are actually modeling.
Are you modeling: (1) the actual "forms" i.e. UI elements, (2) data that might be presented in any number of UI versions e.g. firstName or (3) both?
A data model designed to model forms would have entities like:
Form{
name:string
fields<-->Field.form
}
Field{
width:number
height:number
xPos:number
yPos:number
label:sting
nextTab<-->Field.priorTab
priorTab<-->Field.nextTab
form<<-->Form.fields
}
You would use this to store data about form as displayed in the user interface. Then you would have a separate entities and probably a separate model to store the actual data that would populate the UI elements that are configured by the first data model.
You can use Core Data to modeling anything you just need to know what you are really modeling.
My company is about to start a new project using Telerik's OpenAccess ORM. This is a new product to us, and the first time we'll be using an ORM for a project instead of a Dataset based approach. We are currently having some disagreement regarding the best way to structure our data layer. Specifically, should we have a single .rlinq file and domain model for the project, or should we have per screen/module .rlinq files that contain only the tables, and the columns from the tables, required for that particular screen/module. To illustrate the latter:
Say we have a Person table, with fields for first name, last name, ssn, birthdate, gender and marital status. In the personal information screen, we need all of these fields, so we include the whole table in the domain model in that .rlinq file. On another screen (with a separate .rlinq file), we only need the person's last name and ssn, so the Person object in that .rlinq file contains only last name and ssn.
The argument for this method has been primarily that we should only select the data that we need for a particular screen, and no more. In our current Dataset based applications, this makes sense. There has also been concern expressed that having unnecessary tables and relationships will cause unneeded data to be loaded even if it is not asked for and lead to network load. The argument against this has been that we're fragmenting the domain model and introducing unnecessary complexity, and that part of the job of the ORM is to manage data fetching with caching and lazy loading. We can't come to an agreement on this, and can't find any conclusive information one way or another, so we're turning to the StackOverflow community for help!
If it matters, we're building a Windows Forms based intranet app, and the data layer will be sitting behind WCF services, and the database will have around 100 tables.
Thank you in advance for your help!
In general it is best to have a solid domain model built up in a single RLINQ file. You can then handle screen concerns by projecting queries into ScreenModels/DTOs as needed.
For Example
Say you have a person object with multiple properties, however, on a particular screen you only want to return first name & last name.
var myUserDto = context.People
.First()
.Select( p => new UserDto { FirstName= p.FirstName,
LastName=p.LastName });
OpenAccess is smart enough to only query for the first/last name in this case. Now when the screen ends up requiring another property available in the person object, you only need to update the dto and LINQ query.
Also, if you plan to use the Data Service Wizard OpenAccess provides, it creates a service per OpenAccessContext. So if you have an RLINQ per entity you will have a service per entity, which would be painful to maintain on the client to say the least. If you hand roll the service layer, you would obviously have a little more control here, but you will still need to constantly remember which OpenAccessContext handles each domain object.
FYI, For a large model it may be helpful to look into the aggregate metadata source OpenAccess provides to help break up large models into manageable pieces.
Hope this helps! :)
I am working on a design where I can have flexible attributes for users and I am confused how to continue the design of the schema.
I made a table where I kept system needed information:
Table name: users
id
username
password
Now, I wish to create a profile table and have one to one relation where all the other attributes in profile table such as email, first name, last name, etc. My question is: is there a way to add a third table in which profiles will be flexible? In other words, if my clients need to create a new attribute he/she won't need any customization to the code.
You're looking for a normalized table. That is a table that has user_id, key, value columns which produce a 1:N relationship between User & this new table. Look into http://en.wikipedia.org/wiki/Database_normalization for a little more information. Performance isn't amazing with normalized tables and it can take some interesting planning for optimization of your code but it's a very standard practice.
Keep the fixed parts of the profile in a standard table to make it easy to query, add constraints, etc.
For the configurable parts it sounds like you are looking for an entity-attribute-value model. The extra configurability comes at a high cost though: everything will have to be stored as strings and you will have to do any data validation in the application, not in the database.
How will these attributes be used? Are they simply a bag of data or would the user expect that the system would do something with these values? Are there ever going to be any reports against them?
If the system must do something with these attributes then you should make them columns since code will have to be written anyway that does something special with the values. However, if the customers just want them to store data then an EAV might be the ticket.
If you are going to implement an EAV, I would suggest adding a DataType column to your attributes table. This enables you to do some rudimentary validation on the entered data and dynamically change the control used for entry.
If you are going to use an EAV, then the one rule you must follow is to never write any code where you specify a particular attribute. If these custom attributes are nothing more than a wad of data, then an EAV for this one portion of your system will work. You could even consider creating an XML column to store these attributes. SQL Server actually has an XML data type but all databases have some form of large text data type that will also work. On reports, the data would only ever be spit out. You would never place specific values in specific places on reports nor would you ever do any kind of numerical operation against the data.
The price of an EAV is vigilence and discipline. You have to have discipline amongst yourself and the other developers and especially report writers to never filter on a specific attribute no matter how much pressure you get from management. The moment a client wants to filter or do operations on a specific attribute, it must become a first class attribute as a column. If you feel that this kind of discipline cannot be maintained, then I would simply create columns for each attribute which would mean an adjustment to code but it will create less of mess down the road.