I want to generate a UPI transaction Id on server side . which will be unique (obviously). i am using Spring boot as server side technology and Mongodb as database.
Thanks in Advance
From https://developers.google.com/pay/india/api/web/create-payment-method :
Important: The transaction reference ID is mandatory and must be
unique for every request. This could be order number,
subscription number, Bill ID, booking ID, insurance renewal
reference, etc.
So it is just a reference to your system. Presumably if someone is buying something from you, you are keeping track of it in some Order table or something in MongoDb, for which you are using a unique (possibly auto-generated) Integer primary key, so just use that.
Related
For my app I have a server-side database in which I store users and their data. I am wondering how to keep track of which user has which UUID. I want to make sure that only the same user with their own unique UUID can access their data in the database.
What would be the best way to do this?
In your database, create a table where each row represents one particular user. That table would have their permanently assigned UUID, along with name, email, etc.
Some databases such as Postgres and H2 support UUID as a built-in data type. Some databases proved a feature, perhaps as a plug-in, to generate a UUID value. For example, the uuid-ossp plug-in for Postgres. If not, you can generate a UUID in Java.
When creating an account for a user, create a row in that table. When a user logs in, look up their credentials in this table, retrieving their previously assigned UUID.
During the execution of your app, keep that retrieved UUID in memory as a java.util.UUID object. In a web app built on Jakarta Servlet, a good place to keep their UUID would be as an attribute on the Session. See Binding Attributes into a Session in the spec. See HttpSession#setAttribute and getAttribute.
When you write rows in other tables that belong to a particular user, include a column for their UUID. Include their UUID as a criteria in your queries.
You might want to look into multitenancy as a topic.
After authenticating the user (via your favorite authentication process), add a set-cookie response header with the user id (or any other data you deem appropriate) as the value.
Don't forget to set the cookie properties httponly, secure, and samesite.
I have the following table in my db:
CREATE TABLE document (
id INT PRIMARY KEY AUTOINCREMENT,
productModelId INT NOT NULL,
comment VARCHAR(50),
CONSTRAINT FK_product_model FOREIGN KEY (productModelId) REFERENCES product_model(id),
)
Of course, real table is much more complicated, but this is enough to understand the problem.
Our users want to see the number of the document when they click button "new". So, in order to do that, we have to create object in db and send to client that object. But, there is a problem. We need to know productModelId before we save the object in db. Otherwise we will have an sql exception.
I see two possible variants (both are ugly, really):
To show modal list with product models to user and after that create object in database with productModelId chosen by user.
To create a temporary number and after that to save the object in db when user finishes editing the document and saves id. We also need to remove NOT NULL case and validate this somwhere in code.
The first way is bad because we have too much modals in our application. Our UI is too heavy with them.
The second variant is ugly because our database is not consistent without all the checks.
What can you suggest we do? Any new solutions? What do you do in your apps? May be some UI tips. We are using the first variant at the moment.
Theory says that the id you use on your database should not be a relevant information, so the user should not see it if not well hidden in an URL or similar, so you should not display it to the user, and the problem you have is one possible confirmation of this theory.
Right now the solution you have is partially correct: it satisfies technical requirements, but is still bad because if the user doesn't complete the insert you'll end up with the DB having empty records (meaning, with ID and foreign key ok, but all other fields empty or with useless default values), so you are basically circumventing the database validations.
There are two better solutions, but both require you to review your database.
The first is not to use the id as something to display to the user. Use another column, with another "id", declare it unique on the database, generate it at application, display it to the user, and then use this other "id" (if it's unique, it is effectively an id) wherever needed.
The second one is the one that is being used often cause it does not require a central database or other authority to check uniqueness of ids, so scales better in distributed environments.
Drop the use of the common "id int" auto-incremented or not, and use UUIDs. Your id will be a varchar or a binary, an UUID implementation (like java.util.UUID, but you can find in other languages) will generate a unique id by itself whenever (and wherever, even on the client for example) you need it, and then you supply this id when saving.
We make it the following way.
Created table id_requests with fields issue_type_id and lastId. We need this in order to avoid the situation when two users hit the button 'new' and get the same ids.
And of course we added field innerNum to all the tables we use this feature in.
Thank you!
I'm generating a unique id(generated by the frame work used are, so I should use only this ID and there is no API in the framework to check if this generated by the framework. Thanks RichieHH for pointing this) for each request in the web application and this can be presented back as a part of another request to the system. Now, I am storing these unique ID's generated in the database, and for every request the DB query is issued to check if this ID already exists(this is how the validation is done currently for the unique ID's). Now, if I have to validate the ID sent in the request has been generated by the application with out using the persistent storage, which approach should I be following?
My initial approacht is to generate the ID which adds to particular sum after hashing, but this can be identified after going through the patterns.
It will be great if some one can help me with an approach to solve this problem in a way it can validate the uniqueID generated with in the application. Thanks.
Use UUID, which is pretty standard solution for this task. You don't need to validate UUID, you can assume that it is unique always.
You can use ServerName+Timestamp+some extra. It can be more advantageous for debug but less secure.
I am reading about GAE and its datastore. I came across this question and article. So I wonder if my users can be identified, say, by email, would it be reasonable to use the same parent for all users and email as a key with the goal of resolving conflicts when two different users are trying to use the same email as their identifiers? In theory if number of users becomes large (like, say, 10M), may it cause any issues? From my perspective, gets should be just fine but puts are those that are locked. So if gets significantly dominate puts (which happen really only at the point of creating a new user), I don't see any issues. But....
Key parent = KeyFactory.createKey("parent", "users");
Key user = KeyFactory.createKey(parent, "user", "user#domain.com");
When to use entity groups in GAE's Datastore
https://developers.google.com/appengine/articles/scaling/contention
I also faced the unique email issue and here's what I've done:
Setup a "kind" called "Email" and use the user inputted email as string key. This is the only way you can make a field scale-able and unique in datastore. Then setup another kind called "User" and have the Key using auto generated Id:
Email
key: email,
UserKey: datastore.Key
User
key: auto_id,
Password: string,
Name: string
In this setup, the email can be used as login, and user have the option to change their email as well (or have multiple emails), while email remains unique system-wide.)
====================
It's not scale-able if you put every user under the same parent. You will end up with all data stuck on one particular "server" because entities from the same entity group are stored in close proximity. You will end up facing the 5 writes per second issue
=====================
As a general rule of thumb, things that scales (e.g. user), must be a root entity to enjoy the benefit of data-store scale-ability.
I think I have found the answer to my question. https://developers.google.com/appengine/articles/handling_datastore_errors in Causes of Errors section:
The first type of timeout occurs when you attempt to write to a single entity group too quickly. Writes to a single entity group are serialized by the App Engine datastore, and thus there's a limit on how quickly you can update one entity group. In general, this works out to somewhere between 1 and 5 updates per second; a good guideline is that you should consider rearchitecting if you expect an entity group to have to sustain more than one update per second for an extended period. Recall that an entity group is a set of entities with the same ancestor—thus, an entity with no children is its own entity group, and this limitation applies to writes to individual entities, too. For details on how to avoid datastore contention, see Avoiding datastore contention. Timeout errors that occur during a transaction will be raised as a appengine.ext.db.TransactionFailedError instead of a Timeout.
Is there any way to configure(xml) tomcat (6.x) to generate unique SessionId.
(Without extending ManagerBase/StandardManager).
I am capturing user login details in db table,with Session Id in a column with unique constraint,and am getting unique constraint exception
You should not store the Tomcat-generated session ID as an unique constraint in the DB. This makes no sense. Tomcat's session ID is only unique within all existing active sessions. The Servlet spec does not forbid to reuse the ID of an expired session for a new session at some point, months or years later. With a fixed length 32-char hexadecimal string as session ID, all possible IDs are not "unlimited". You can't prevent it from being reused for a different client at some point.
I do not understand why you would ever store a Tomcat-generated session ID in the DB lifetime long. You should remove it from the DB whenever it has expired. Or you should solve your problem differently. As you didn't state anything about the functional requirement behind this "solution", I cannot give a more suited answer. Here are however some hints:
Do it the other way round: insert or select the necessary data in/from DB, get the DB-generated ID and store it as an attribute of the HttpSession. For example the logged-in user ID, or just the whole User object.
Or, if it needs to expand the default lifetime of a session, e.g. "Remember me" option, then you should generate an UUID yourself (and test if it doesn't exist in DB yet) and use it in a separate cookie instead.
I'm working on this issue myself, and I'd like to mention that it is possible to generate a guaranteed unique ID using 128 bits (32 hexadecimal digits) using UUID. It is based on UTC time, and is guaranteed to be unique as long as the usec timestamps at which different UUID are generated are different.
See also RFC4122: https://www.ietf.org/rfc/rfc4122.txt
Java has a standard class for generating these IDs:
http://docs.oracle.com/javase/6/docs/api/java/util/UUID.htm
Just use a compound primary key, as CONSTRAINT PRIMARY KEY ("SID" , datum);