I'm looking for implementation ideas for the following scenario:
I have a search screen with a bunch of dropdowns and free form text fields/text areas. I would like to provide the option of saving the search criteria for the logged in user so they can reuse that criteria later if they want to. Some options I could think of are name/value pairs, XML & serialized objects. Are there other options and what are your recommendations on the best option. We use glassfish, hibernate, oracle, j2ee 1.4 & java 6.. Thank you for your help!!
I think as part of your validation logic you can persist the name value pairs that were used for search. For enterprise there are no personalization features that can be easily adopted, depending upon the requirements we have to go with one of the above.
Related
I am trying to build a java based web application using Spring Boot and REST architecture using Spring MVC for the following purpose:
Search car parts through multiple set of criteria.
I try to explain it in different scenarios:
find part A of Brand B for Make C of Model D of year x.
find out what parts are available of Brand B for Make C of Model D of Year x.
Search multiple items at once for Vehicle C of Model D of Year x. For example if an engine is damaged and I want to quickly find out whether I have the parts (like pistons, cylinders, gaskets, etc.) in the supply. The result of this search is a list of the parts with their brands and prices.
My primary concern at this moment are the following two questions:
How should I model the data so that the search scenarios are achieved efficiently? What I mean is that how the relation between the entities in the Java and the persistence system should look like?
What kind of database should I use? SQL or NoSQL?
All the REST end-points will return Json objects.
I will be using Angular with Bootstrap for the front-end
Isn't this scenario a typical "faceted search"? I think that any solution designed to implement faceted search should work fine. For example Solr or Elasticsearch.
The advantage of the "faceted search" for the end users is the option to refine the search. Users can start with a broad search and the system will provide refining filter criteria, based on the current search results.
Today, all the major e-commerce sites have a kind of faceted search and every search engine support this type of browsing.
It seems to me that engines like Solr and Elasticsearch are the more natural solution, but even a standard RDBMS like Oracle has support for faceted search.
Faceted search in Solr
Filters vs. Facets: Definitions
I would put the focus on modelling it cleanly rather than efficiently - unless you already know that you will have a massive amount of data. Having it structured cleanly will make it easy to optimise if that is required later.
Normalise your data - there will be plenty of information out there on how to do this. The car industry is becoming more consolidated so many parts are now shared across different models and even different brands.
An ORM like hibernate can be used to map your entities to your tables. Spring provides extra support in this area which you might consider as you are already plan on using Spring MVC.
I have a problem that bothers me for quite some time, and I also came up with a solution, the question here is rather on how to best implement it, so I'm seeking advice from you if you've ever dealt with that situation before (it's hard to find anything useful on this topic on the web).
Situation
3-tier architecture (rich client such as Swing or Eclipse RCP or Android, web application with implementations of the service layer, relational database).
My models are POJOs (plain old Java objects, pure data containers with getters and setters), which are persisted (technical ID on all my models).
I'm often dealing with large models that are aggregatively used, but need to be efficiently read and transported. Let's say I've got following models:
User, with login name, password hash, salt, first/last name, e-mail address, authorization credentials, profile picture (Image)
Image, with name, content type and (usually large) data
Article, with text, and author (User)
Problem
Now when I'm listing or loading an article, I don't want to load the entire author (User), as it exposes too much details (password hash and salt) and carries too much data (credentials, image) for what I actually need in the context of an article (first/last name and e-mail).
Generally speaking: sometimes I need the full details of my models (when creating/editing them, or in very specific situations), but when I use them aggregatively in other models, I'd rather have a simplified form (if I need details, I could load them with a separate request).
Solution
For each model, I could create two variants: a full detail variant with full CRUD (create, read, update, delete) and a simplified, read-only variant, which can be used as a surrogate in aggregative relationships. The simplified model version also contains the technical ID of the detail version, so I could fetch that by demand.
For the User: the simplified model just has the first/last name and e-mail.
For the Image: the simplified model comes without the image data.
The article's author is the simplified version of the user, and the User's profile picture is the simplified version of the image.
Question
Is this an existing pattern? It somewhat relates to DTO (Data Transfer Object), but it's not the same. Has anybody seen this before?
Have you used something like this before? Any advice or tips on the naming, OO-relationship between the two representations?
I cannot correlate your solution option to a pattern that i am aware of. But your requirement(s) can be fulfilled by introducing a very thin API (Web API) on top of your service later.
There are two parts to it,
Reading: as you've mentioned, you may need to funnel specific selection of data items to the consumer based on the usage/permissions. This can be accommodated by specifying a set of facets in your incoming GET query.
Check here for a sample, https://developer.linkedin.com/documents/people-search-api
Writing: For fragments, use PATCH operations. This will give you the flexibility to update by field.
Check here for a sample: https://www.mnot.net/blog/2012/09/05/patch
All in all, what this gives you is a very flexible API with a very clean domain model under your API. And this is a widely accepted approach these days.
Hope that helps.
As the title says, i have a need to create a dynamic menu stored as a tree in the database and there are plans to put an interface on it.Now i need to decide how to implement the Access Control Layer based on what is on the market suitable for this requirement.
I heavily use Spring IoC, spring mvc etc....with hibernate for my project. I've used apache shiro before and it's not bad.just that the community is still young so it takes time for a question regarding shiro to have contributions and there is not extensive documentation.
I was still planing on using shiro anyway because i've an experience which i don't have with spring security.Now the first question should have been Is is a good idea to tie ACL to menu system|navigation system .I would be please if anyone could share his experience regarding that.
So on top of my head i have this model in mind users, roles, rights, users_rights ,roles_users, roles_rights
users //contains creds and user detail
roles //contains roles
rights // contains rights (including menu entries matching rights, if i have to tie them)
roles_users //many-to-many roles-users with extra columns mapped as entity
roles_rights // many-to-many roles-rights with extra columns mapped as entity
users_rights //many-to-many users-rights mapped as entity with extra columns. special rights for user and overwrite the overall rights given by roles. can deny rights given by a role or add rights not inside any roles
so in the rights table i could have like:
id
name // in the form of admin:users:list
description
menu_name // unique name what shows on page
menu_url
the only question is that how do i handle submenu? self many-to-many rights-rights?
at the end it all becomes so complex.So i would like have other perspective, insights ,suggestions. thanks
I hope I understood what you want.
I think that using a self foreign key is valid.
However, I would suggest that you compute the "ACL value" of a sub menu upon its creation, or upon update of one of the parents,
So you won't spent time calculating it while during ACL check for the sub menu.
I'm sorry if I didn't use the terms correctly,
What in general I mean is that if you have some value at a tree, and this value might be dependent on the value of the parent node in the tree,
you should consider to calculate the value for the child node/leaf during insertion , update, or any change at one of the ancestors.
Our's is a product specific to a domain.Here are some of the typical security use cases,
A normal User can edit only his profile data or anybody data based on permission
A user can see only data that belongs to his department while another user can data from all departments
These requirements changes from customer to customer so we can not just hard code the filtering logic in our application code or maintain multiple versions of the application.
We use Hibernate criteria based filtering and like to add additional Restrictions based on some expressions associated with a Permission. An expression for use case 1, mentioned above, may look like this, 'userId=user.userId' where 'user' is a keyword and represents current authenticated user and 'userId' is a property of the object for which criteria is created.
We want to define a dsl using which we can derive criteria restriction as well as 'where' clause for sql.
Are there any existing frameworks which will enable us to do it, without going for dsl? Based on the use cases mentioned above, do you think it can be achieved in different way?
Additional Info: We define only domain objects with some meta information to generate UI. Persistence, security etc are taken care by our core framework.
Have you tested Hibernate filters?
They are great mechanism for record level filtering, you can define multiple filters (for example two filters for your case) on each entity and enable or disable them according to current user.
Shall mention that filters can accept parameters (for example your current user id).
We have used this great feature of Hibernate 3 on a large project, which had a hierarchical organization unit and that worked fine.
By the way if you use Oracle as your database, consider Oracle's virtual private database feature.
We decided to go with our own dsl using antlr
I have a question regarding how to model a many-to-many relationship in App Engine:
A Blogentry can have many tags, a tag can apply to many blog entries.
I see a couple of scenarios:
Use a Set of Strings as an attribute on the blog entry.
This allows me to easily query for an entry using a tag
This does not allow me to fetch all tags and their weights (how many entries they apply to)
Use an unowned relationship between an Entry and a Tag class (Set of keys for Tags in Entry class and vise versa)
This allows me to fetch all tags and their weights
This is much more comples to maintain
Are Set attributes lazyloaded, or would I fetch the entire graph of object every time? (Fetch an Entry, which fetches a number of Tags, each in turn fetching a number of Entries)
use 1. but maintain data on tags and their weights seperately
This has synchronisation issues between the Tag data and the tags in the Entries
Any input and pointers would be appreciated. I think this is a quite common scenario but I haven't seen any good solutions yet.
Like many other database management systems, many-to-many relationships are not natively supported in App Engine Datastore, but could be solved through a "junction table". However, since App Engine's query language does not support joins, this will be very painful to use in your application. Google's BigTable architecture in fact discourages this, because distributed joins are not efficient.
So, I suggest going with the "keep it simple stupid" rule; use the simplest thing that works. A list of strings in a "Blogentry" object sounds fairly robust. Even if it's prone to race conditions (people making updates in parallel, overwriting each other's changes), but how many people do you have editing the same blog post anyway?
I decided to go with option 3., to maintain a seperate list of tags with their weights.
This seems to work ok, although the insert/update code is a bit cluttered.