I'm looking for the best practices if I want to use Grule Golang rule engine with DB as data source. I would like to have one of rule which will check if user ID exists in DB. Currently I have 2 idea. Pass separate field in input strict with boolean value telling if user exists or somehow execute function during rule matching. Do you guys know what is best practice in case of combining Grule engine with DB results?
Related
I'm in need of entering a few data points in the UI of a FileMaker app that are used either for search or for computation, but that have no relation to any field in a database (and don't need to be saved). So I want to add an input field without having it tied to a table field, and it seems that's something FileMaker just doesn't do.
Two use cases:
a) I want a custom search/filter interface instead of using the FM one. My users should see two calendars, pick two dates and the data is filtered by those (between them), as well as additional criteria, which don't directly translate to field searches. I know I can use "startdate ... enddate", but I'd like a more user-friendly interface.
b) Users enter a few data points into seperate fields which are then computed and combined into one database field by script. This is technical data that is entered by copy-and-paste and needs a bit of parsing before I put it into the database. Again, I'd like a field that isn't related to the database, put a script trigger on it, and when data is entered there, it is parsed and put into the actual DB fields.
Is it possible at all to have input fields not related to a database in FileMaker ?
If not, what's the best practice? I thought about setting up a dummy table with various fields I can use, but maybe there's a better way?
You should read up on global fields. They can be in any table and are accessible from all tables. They do not retain their value after the session is closed if the file is hosted. Use a script to perform a search based on what the user types in the global field.
I am writing a multi-language dictionary app. When the user selects a language to use data from, that language should apply to every page until they select a different language. Ideally, the language should be part of the URL so that the address for the English word "double" and the French word "double" is different. It should also be possible to specify no language, so that "double" would display both the English and the French word. I will also want to filter the data on multiple fields at the same time, e.g. the word itself and the language.
I'm trying to fit this into the Laravel resource concept. The index view of Word should show all words filtered by the language, or not filtered if no language is specified. create should keep the language from index. store should just use the form data. The language can be included as a hidden field in the create view if it's been specified. show doesn't strict speaking need a language filter, but if the user then goes back to index, the filter will still need to be applied.
I started using routes, but that means I'll have to hard-code a route for every filter. I've also thought of using session data, but that means the URLs wouldn't include the filter. If the filters are appended as a query string how would Laravel access them? Is this a good solution?
I'm using Laravel 5.8. What's the best Laravel way to persist this type of data filter across views?
I have similar issues in many areas of our apps. We occasionally use Session for this, but generally find the most efficient and easiest way to solve this is to attach a database field to the user object.
If you are using any type of auth, Laravel is already going to boot the user object on every page view, thus the filter can be pulled with no extra calls to the database. If no language is specified, the \Auth::user()->current_lang_id will be null, and thus no filter would be applied. We typically use a relationship (e.g. 'currentLang()') which makes it easy for the user to see the language and can automate binding on the form.
The nice part of this, we've found, is that it individualizes it per user, and it 'remembers' the user's preferences between sessions in a simple way - no need to make dozens of routes or a special variable + logic on multiple routes because those routes include your filter. Instead, you can put your logic at the top of a base controller and be done with it.
Lastly - changing the language when it is a db field on the user is just standard, simple CRUD.
HTH
Before anything, i must say this first: This table design is not my decision. We protest but to no avail, so please don't tell me, don't create a table like that.
We have a database with each table have a flag. This flag used to indicate which environment this row belong to, production or test data.
For server side, we have one variable which currently stored in ThreadLocal to indicate which environment this request belong to, same value as the flag in database.
Our requirement is that if my request belong to test environment then we must select only record belong to this environment. We would need to add a condition to every query we made to database, something like:
SELECT t FROM TABLE t WHERE t.flag = :environment
But we have to update every single query, update every object to set this flag before insert/update into database. This will require a lot of effort as our system already built long ago, not on progress. Also this will bring a lots of risk if someone forgot to add this to any new query.
So is there anyway to insert a condition to check this flag value for every query without have to manually edit the query string? Like an interceptor or something to put this condition in?
Which JPA provider?
With Hibernate, you could try using a #Filter.
Multitenancy could be another option, but probably an overkill in your scenario.
Finally, since you flagged the question with Oracle, perhaps the easiest approach would be to provide dedicated schemas (per environment) with views for every single table in your db, filtered by the flag column. Not sure if you're allowed to do that, though.
With some of the above, you would need a global entity listener to populate the flag field of your entities before they are persisted.
I'm upgrading an old procedural site to laravel 5.2, and I'm struggling with the old routes I made.
On this website, the routes were made like this : {user_slug}/{content_slug}.html. For the moment, I use cviebrock/eloquent-sluggable to generate the slugs, but I'm open to another one if this one cannot meet my needs.
I have two questions :
Can I make the content-slug unique, but per user ?
How can I write the route and the controller in order to match the correct user slug ad the correct content slug ?
I have not done this myself but I believe there would be a way in the validation rules to do this. Here is an untested rough draft to check content_slug in the posts table but only check uniqueness where the user_id field equals a variable:
'content_slug' => "unique:posts,content_slug,NULL,id,user_id,$user->id"
Depending on who you ask, they may advise you (either instead of or as well as doing the above) to set up a key in the database based on the user_id and content_slug fields. This way the database returns an error if an insert is attempted as well as gives a performance boost when running a query off that index. Queries off of an index can literally give an exponential performance increase.
There seems to have no way to enforce uniqueness in Parse. I have a parse object in which one of the fields is a url. I require that url to be unique as it is the most important field in the object: everything else is meta data about it. So is there a way to override the objectId of a Parse Object? That way I can always check for existence in a simple way before trying to create the object.
Actually this might still fail. So any ideas that do not include cloud code?
I know this can be done because Parse is able to ensure username and email are unique for each User object. I am hoping it's an elegant solution and someone here knows how I might accomplish something similar. After all, database tables with unique fields are commonplace.