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).
Related
I want to make access polices on the folder each of costumer:
DocumentLibrary/Custumers/CostmerA
DocumentLibrary/Custumers/CostmerA
.
DocumentLibrary/Custumers/CostmerN
Then the CustomerA (tenant user) can't access the folders of other another Customers
I think abut doing this using "Tenants", and a would like to see an exeample.
The Multi Tenant (MT) feature in Alfresco does not do what you ask for. Especially, tenants don't share the same document library, they are completely separated.
You could use MT to achieve complete separation of tenants. This separation would include not only documents but users, groups, permissions, everything you deploy in the Data Dictionary.
I recommend to use a single (default) tenant and normal folder permissions if you just want to handle read/write permissions.
Before using Multi-Tenancy, pay close attention to the features you will be giving up, which are documented here.
The correct way to do what you are attempting to do is to simply use permissions. Give all of your customers access to the /customers folder. Then, in each customer-specific folder, break the ACL inheritance (Manage Permissions, Un-check Inherit Permissions), then assign the specific customer (perhaps using a group) to the folder with the appropriate access.
You might even consider using a separate Share site for each customer, which would make this easier.
The caveat to this is that if you are trying to hide all of your users and groups from each other, then really what you want are separate repositories, and that's what Multi-Tenancy provides, at the expense of the features I referenced at the top of the post.
If you go that route, you'll have to use the tenant console to create each customer-specific tenant. Your tenants will be separated into their own repositories. And you won't have a way to view all of your customer documents side-by-side without switching tenants.
Honestly, due to the stability of the multi-tenancy feature and the other features you have to give up, I'd be more inclined to use completely separate servers, even though that increases your maintenance burden. Alfresco doesn't even use their own multi-tenancy feature in their own cloud product.
You really should have no problems. MT is already there, you just need to enable it. There's no additional work that you should do in order to hide tenants from each others - that's the whole point of this feature.
http://docs.alfresco.com/5.1/concepts/mt-intro.html
I've been trying to get my head around NoSQL, and I do see the benefits to embedding data in documents.
What I can't understand, and hope someone can clear up, is how to store data if it must be relational.
For example.
I have many users. They are all buying a product. So everytime that they buy a product, we add it under the users document in mongo, so its embedded and its all great.
The problem I have is when something in reference to that product changes.
Lets say user A buys a car called "Porsche". Then, we add a reference to that under the users profile. However, in a strange turn of events Porsche gets purchased by Ferrari.
What do you do now, update each and every record and change to name from Porsche to Ferrari?
Typically in SQL, we would create 3 tables. One for users, one for Cars (description, model etc) & one for mapping users to purchases.
Do you do the same thing for Mongo? It seems like if you go down this route, you are trying to make Mongo do things SQL way, which is not what its intended for.
I can understand how certain data is great for embedding (addresses, contact details, comments, etc) but what happens when you need to reference data that can and needs to change at a regular basis?
I hope this question is clear
DBRefs/Manual References were made specifically to solve this issue. Instead of manually adding the data to each document and then needing to update when something changes, you can store a reference to another collection. Here is the mongoDB documentation for details.
References in Mongo
Then all you would need to do is update the reference collection and the change would be reflected in all downstream locations.
When i used the mongoose library for node js it actually creates 3 tables similar to how you might do it in SQL, you can use object id's as foreign keys and enrich them either on the client side or on the backend, still no joining but you could do an 'in' query for the ID's then enrich the objects that way, mongoose can do this automatically by 'populating'
I would very much appreciate any information regarding this. I have got a database that follows the correct principles, I say this because I used approached it using ERD and Normalisation to data model the database.
I am using this database for a web program that I am developing which has got a Login system. I am aware about the login system that can be implemented using the one table e.g. user table and having an extra field to define the authorisation level of the user within the system which will be so much easier to develop. But on the other hand I am confused as an compsci student to whether doing this will degrade my marks since it isn't the correct principle.
Just to clarify the database I've designed have got 3 different users and have relationship to different entities.
Thank you so much for your time and reading this !!!!
So you have three different types of users, and you want to impress your teacher by not merely using one table.
A good schema would be:
users
for all the things they have in common
common_data , admin_data, and organizer_data
The former for regular login/authentication -
username
hash (password)
access_level (or type)
-- and you might even include:
last_login
Or you know, whatever.
and in the other tables, have the generalized information
(that you would be reading less-often)
email
phone_number
address
etc --
For the organizer_table, you might have groupID, which of course, you could also put in the user table -- admin_table would get something like failed_login_attempts -- or in some of my projects, I have "last_ip_address" for the admin -
But you get the idea --- separate user-entities, that require separate data-sets -- since this project doesn't seem to be very code-oriented, I'm sure you could get away with making up whatever columns that seem remotely logical
And of course, both tables get an id column - which provides their relationship !
Now, insofar as one table making it easier than two - you should look into JOIN's - which make two tables appear as one when you need them to - otherwise, they can be separate entities--
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.
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! :)