I'm building an auction site using laravel 5 however I'm currently unsure of the best way to go around the bidding process.
I currently have it set-up so that once the user hits a bid button the script runs to place the bid, however if multiple users do this at the same time this causes issues with multiple bids with the same value. I thought about modifying this so that it would queue the bid that way only 1 bid is being processed at once however I believe there will be a better method.
If someone could point me in the correct direction it would be greatly appreciated.
One way to do it is to simply insert the bid with a high precision timestamp immediately, then check the table using a select and see if its actually a leading bid or not. The table should have an auto incrementing id, so even if two bids have the exact same timestamp, sorting also by id will tell you which one was actually received first.
Related
I'm building a graphql schema through AWS AppSync and have a question regarding schema structure. My app will show users new posts and have them either join or pass on them. I'm trying to build in a way that I will only show users new posts and not repeat or at least not repeat for a certain amount of time. It's similar to swiping on tinder, they don't show you somebody again if you've already swiped on them. Does anybody have any ideas how to structure this in my schema. Do I need to store references to all of the seen posts in the user model or should I store each swipe as its own model and how should I structure the querying? I'd appreciate any advice on this.
Thanks!
Assuming a post has a creation time, you could keep track of the last (max created time) post they've seen, then display anything after that.
But think about what happens if they've been off the app for 5 minutes, or 5 days, or 5 weeks... depending on the volume of posts you anticipate they could quickly get behind and have to wade through too many older posts.
One thought would be to show the next oldest post, based derived from the creation time of the most recent post they viewed. Unless N number of posts were created since the last time they were online (a threshold you'd have to decide). Then start with displaying the N - Xth post (where X is 5, or 500, again depending on volume) until they're all caught up.
There are lots of ways you could program it, it all depends on your use case, you may want to take "popular" posts into account for example, those might be weighted above/before the other posts in their backlog.
Hope this helped.
I got a screen (block) in which users make requests for a specific product and I validate the number of items available in the database at the moment of the request, before they commit, which is suposed to reduce the existence ot the item requested.
The problem I'm facing is... if several users are making the request at the same time they all get the existence available before a complete request has been done by a user. So when another user makes the request, the existence in the datase is unreal for that particular user.
I think of validating the existence of the product again before commiting the request to the database, and display a message to the user that the existence has chaged since the he first logged in. I don't know if that is a good solution. I need your expiience in this type of situation.
How can I control the existence of an item while several users are making requests at the same time?
I just need the basic idea so I can continue with the code.I think the problem is independent on language I am using.
I'm not sure this is really the answer to your question as I never used Oracle Form. But, generally speaking, to face that kind of issue, you should use atomic test and set queries. Sounds scary, isn't it? But really simple:
Say at a given point, one of your users saw that inventory:
SELECT * FROM INVENTORY WHERE PRODUCT='LEMON';
ID PRODUCT QTY
2 LEMON 200
There was 200 lemons in stock at the time of the SELECT query. But maybe, those has been sold out by now. Maybe. Maybe not.
If the user seeing the 200 lemons decides to check out, say 100 of them. You can only do that if there is still 100 or more lemon at the time of UPDATE. Concretely you will write:
UPDATE INVENTORY
SET QTY=QTY-100
WHERE PRODUCT='LEMON' AND QTY >= 100;
That way, you only update your table if enough lemon left at that time. Since Oracle ensure that only one statement can update a row at a time, all concurrent requests to update that row are handled sequentially. In addition, by the use of the WHERE ... QTY >= 100 Oracle will check the number of items remaining at UPDATE time.
You have to be prepared (and you must check!) the outcome of the statement to see if one row was updated or not. It no row was updated, that means there wasn't no longer enough lemons in stock at the time of update.
I have something similar to twitter's feeds where we load it in real-time. How do i track how many people have seen a tweet? I am not talking about if you go to domain.com/post/32434 and that loads a status. I am talking about AJAX real-time query where one post is being loaded one after the other.
Will Google Analytics or Charbeat have anything that will help fulfill this need for me?
Why not managing your own counter in the database?
I don't really know your criteria, but let say you basically want to count how many times a given tweet was loaded.
Very quickly, I could think of this:
The table:
CREATE TABLE tweets_loads(ID_TWEET INT NOT NULL, LOADS BIGINT NOT NULL DEFAULT 0, PRIMARY KEY `ID_TWEET`) ENGINE=InnoDB;
The query at each ajax request:
INSERT INTO tweets_loads (ID_TWEET, LOADS) VALUES (myTweetId, 1)
ON DUPLICATE KEY UPDATE LOADS = LOADS + 1;
(Assuming mysql)
Run it from php and that's it... Up to you then to check competition between inserts though, but in theory mysql should handle it just well...
We use CRM 4.0 at our institution and have no plans to upgrade presently as we've spend the last year and a half customising and extending the CRM to work with our processes.
A tiny part of model is a simply hierarchy, we have a group of learning rooms that has a one-to-many relationship with another entity that describes the courses available for that learning room.
Another entity has a list of all potential and enrolled students who have expressed an interest in whichever course.
That bit's all straightforward and works pretty well and is modelled into 3 custom entities.
Now, we've got an Admin application that reads the rooms and then wants to show the courses for that room, but only where there are enrolled students.
In SQL this is simplified to:
SELECT DISTINCT r.CourseName, r.OtherInformation
FROM Rooms r
INNER JOIN Students S
ON S.CourseId = r.CourseId
WHERE r.RoomId = #RoomId
And this indeed is very close to the eventual SQL that CRM generates.
We use a Crm QueryEntity, a Filter and a LinkEntity to represent this same structure.
The problem now is that the CRM normalizes the a customize entity into a Base Table which has the standard CRM entity data that all share, and then an ExtensionBase Table which has our customisations. To Give a flattened access to this, it creates a view that merges both tables.
This view is what is used by the Generated SQL.
Now the base tables have indices but the view doesn't.
The problem we have is that all we want to do is return Courses where the inner join is satisfied, it's enough to prove there are entries and CRM makes it SELECT DISTINCT, so we only get one item back for Room.
At first this worked perfectly well, but now we have thousands of queries, it takes well over 30 seconds and of course causes a timeout in anything but SMS.
I'm given to believe that we can create and alter indices on tables in CRM and that's not considered to be an unsupported modification; but what about Views ?
I know that if we alter an entity then its views are recreated, which would of course make us redo our indices when this happens.
Is there any way to hint to CRM4.0 that we want a specific index in place ?
Another source recommends that where you get problems like this, then it's best to bring data closer together, but this isn't something I'd feel comfortable in trying to engineer into our solution.
I had considered putting a new entity in that only has RoomId, CourseId and Enrolment Count in to it, but that smacks of being incredibly hacky too; After all, an index would resolve the need to duplicate this data and have some kind of trigger that updates the data after every student operation.
Lastly, whilst I know we're stuck on CRM4 at the moment, is this the kind of thing that we could expect to have resolved in CRM2011 ? It would certainly add more weight to the upgrading this 5 year old product argument.
Since views are "dynamic" (conceptually, their contents are generated on-the-fly from the base tables every time they are used), they typically can't be indexed. However, SQL Server does support something called an "indexed view". You need to create a unique clustered index on the view, and the query analyzer should be able to use it to speed up your join.
Someone asked a similar question here and I see no conclusive answer. The cited concerns from Microsoft are Referential Integrity (a non-issue here) and Upgrade complications. You mention the unsupported option of adding the view and managing it over upgrades and entity changes. That is an option, as unsupported and hackish as it is, it should work.
FetchXml does have aggregation but the query execution plans still uses the views: here is the SQL generated from a simple select count from incident:
'select
top 5000 COUNT(*) as "rowcount"
, MAX("__AggLimitExceededFlag__") as "__AggregateLimitExceeded__" from (select top 50001 case when ROW_NUMBER() over(order by (SELECT 1)) > 50000 then 1 else 0 end as "__AggLimitExceededFlag__" from Incident as "incident0" ...
I dont see a supported solution for your problem.
If you are building an outside admin app and you are hosting CRM 4 on-premise you could go directly to the database for your query bypassing the CRM API. Not supported but would allow you to solve the problem.
I'm going to add this as a potential answer although I don't believe its a sustainable or indeed valid long-term solution.
After analysing the indexes that CRM had defined automatically, I realised that selecting more information in my query would be enough to fulfil the column requirements of an Index and now the query runs in less then a second.
I've got a Rails app where I need salaries to be paid every month for instance. So I need to store the last time the salaries where paid somewhere.
I don't want to use database because I don't want to create a table just for that, I think it doesn't make much sense. I've thought of writing it to the cache but I don't know if the data is secured and can't be lost.
Has someone got an idea of a place where I can store this time ?
Thank you in advance.
You could add the salaryPaid variable to the employee model, and update it each time you pay the salary (or whatever is equivalent for your app). This would still use a database but it would just make a new entry for each employee and would be easy to manage with migrations.