We expose a service that allows clients to create a MUC room in Ejabberd with a given expiry time. After this time, the room should be destroyed, regardless of whether the room is active.
We currently achieve this by:
Setting custom expiry time metadata in the room options when creating a room.
Running a cronjob that queries Ejabberd for all online room names, queries each of these names for their rooms options, and requests that the room is destroyed the expiry is up.
This approach is very naive and, as the number of rooms grows, we see the list online rooms admin call fail at an increased rate with the following error:
2021-04-28 15:24:57.011582+00:00 [error] REST API Error: muc_online_rooms_by_regex([{<<"regex">>,<<".*">>}, {<<"service">>, <<"ourchatservice">>}]) -> error:{badmatch, {error, notfound}} [{mod_muc_admin, get_room_config, 1, [{file, "src/mod_muc_admin.erl"}, {line, 814}]}, {mod_muc_admin, build_summary_room, 3, [{file, "src/mod_muc_admin.erl"}, {line, 394}]},
We suspect the list error is probably related to the large volume of MUC rooms we are working with - in the tens of thousands - and we are looking for a way we can support this feature without expensive operations like listing all online rooms.
muc_online_rooms_by_regex([{<<"regex">>,<<".*">>
I wonder why using muc_online_rooms_by_regex with a regex as useless as .* instead of simply using muc_online_rooms...
We expose a service that allows clients to create a MUC room in Ejabberd with a given expiry time. After this time, the room should be destroyed, regardless of whether the room is active.
Running a cronjob that queries Ejabberd for all online room names, queries each of these names for their rooms options, and requests that the room is destroyed the expiry is up.
The rooms have a very strict and definitive expiry time, like replicants in Blade Runner, that not even their god can extend their life?
In that case, you can include that expiry time in the own room name, so that you don't need to query rooms details: the room name itself would say when the room should be destroyed: bluetag_review__expiry_20210508#conference.localhost
In that case, it would make sense to use muc_online_rooms_by_regex to list rooms that have in the room names the expiry date of today, or previous days.
Related
I like to prevent the last-service double- or cross-bookings.
at the moment many users can check the availability (at the same time) for the same service, getting the availability and all can book the same service/ on the same date. which is a big problem and caused over-bookings.
any idea how to prevent this in Laravel?
Thanks
You need a way to know how many users have booked for a particular service for a particular day
You also need to set a max number of bookings for each service for a day
Just before you save which user has booked a particular service, you can check if the service is fully booked, by checking the number of users that have already booked the service for that day if it is less than the max number of bookings and act accordingly
if you need more clarification or need help designing the database, ask
I am planning on creating a database to track user's time in/time out M-F. Every week should begin on monday and run through sunday.
I have a table filled with my entire user population, so I know which users I need to create entries for and where they belong to. I have proposed so far, a table consisting of the following fields to track the entries (along with example data to fill the fields):
Field Name in table (Example of possible data)
---------------------
Employee (John Smith) 'String
Unit (Quality Assurance) 'String
WeekOf (9/9/13) 'date
InMonday (6:30) 'string, validate either a time in/out or N/A if holiday/vacation
OutMonday (3:15) '^^
HoursWorkedMonday (8.00) 'total hours worked
VacationMonday (0.00) 'if N/A for time, should have hours here
OvertimeMonday (0.00) 'any additional work hours should go here
For this instance, I would have to create In/Out for each day of the week (and perhaps track the date that each day is for). Is this extraneous or is there a seemingly better organization to tracking weekly time measurements? Should I use one table with a unit indicator or multiple tables for each unit?
Usually it's one table with a Date field, an In field and an Out field. That's pretty much standard timesheet data. Take a look at how this guy has it set up.
Make sure you're using an Employee ID in the timesheet, and then you would have a corresponding Employee table with all relevant info (ID, Name, Address, whatever else you store on him/her).
While this project is technically feasible, I have to question the value of making it yourself in Access.
The main issue is with security:
As a desktop program, this can be very easy to hack without precautions. Keep in mind that with Access, the user interface and the designer interface are by default the same thing.
If this is going to be a simple, straightforward db, a motivated user just needs to open the navigation panel and they can add/edit/delete all the timesheets.
If you hide the navigation panel, the user can just do a quick google search and learn to hit F11 (or find it by accident, either way)
You can try regularly (daily? hourly?) transferring the data from the publicly accessible back-end to an archive db that is not accessible to the general users. This can work, but still gives them a window to edit records. And if you don't do the transfer right, they can still add old records.
As a webform on a SharePoint, this can be fairly secure. I'd recommend this if you have Sharepoint.
You should also consider your development time. This is a very common business task across many industries, from restaurants to factories to schools. As such, there's a huge number of cheap web-based options already out there that you can start using today. I'll even assume some of these include summary reviews breaking out numbers by departments as well.
I've never researched these myself, but a quick google search found this interesting page: http://en.wikipedia.org/wiki/Comparison_of_time_tracking_software
I want to design a traffic exchange script that counts incoming traffic and tries to return a n:m (1in:2out for example) ratio of traffic. In the database, I want to have the sites info (SITE), then track traffic by site and ip (DAILY-HITS), then I want to have the trade counted per hour or day - not sure yet (SITE-TOTAL-HITS). I would love any suggestions I can get for designing a well designed database for handling traffic trades.
Right now I'm worried about tracking the incoming hits, later worry about returning. So basically my real question is, how can I design a database that can be efficiently used for returning the perfect amount of traffic for say the last 24 hours. The problem I'm having is, when it comes to programming, I want to have the best designed database for getting information on the last 24 hours and making sure I stay within the n:m ration. Heres what I've designed so far for the database:
SITE (just basic info):
id,
url,
title,
description.
DAILY-HITS:
id,
site_id,
ip,
date (include time - will be broken down per hour),
amount (count how many hits from this ip for this hour).
SITE-TOTAL-HITS (probably be updated every hour via script - useful later for counting last 24 hours):
id,
site_id,
year,
month,
day,
hour.
Any tips, suggestions or point me in the right direction would be greatly appreciated. Thanks in advance.
Here is my take on it for what it's worth:
Site:
Same as what you have
Traffic:
id,
site_id,
ip,
request_DateTimeStamp <- this is a date and time for the url request
no count here, just logging here is why:
assume you do have a count column
- url is requested
- lock up a record in the database with the same date and hour and ip
- Found, update the account
- Not Found, Create a new record and set the count to 1
this is a long process for a table that will presumably be updated a lot, within an hour span multiple request from the same ip will try to update the same record and they will have to wait on each other.
take out that count column and your process is simply to log the incoming traffic by always creating new records.
as far as data analysis is concerned, you can do it in couple of ways:
you can try building cubes: http://datacharmer.blogspot.com/2010/01/multi-dimensional-cubes-in-mysql.html
or you could create information aggregation tables like site_total_hits and just update them using nightly jobs or is often as you wanna run them depending on how accurate they have to be.
these are my 2 cents :D
You can use HitLeap to do that.
What is HitLeap? HitLeap is a Traffic Exchange, also known as an autohits service We help you increase your website hits, rankings (alexa, google) and more. Our affiliate program gives cash and traffic commissions of up to 50%. How does it work? After signing up, you will submit all the websites you want to send traffic to. Then you will earn free traffic by viewing other people's websites. Alternatively, you could buy a traffic package from us.
Go tho this link to sign up
Good Day,
I'm currently designing database structure for a website of mine. I need community assistance in one aspect only as I never did something similar.
Website will include three types of the payments:
Internal payments (Escrow kind payments). User can send payment to another user.
Deposits. Users add fund to their accounts.
Withdrawal. User can request a withdrawal. Money will be sent to their bank/PayPal account.
Basically, I need some tips to get the best design possible.
Here's what I'm thinking about:
deposits - this table will store info about deposits
deposits_data - this table will store info about deposit transaction (ex. data returned by PayPal IPN)
payments - table to store internal payments
withdrawals - table to store info about withdrawal request
transactions - table to store info about ALL transactions (with ENUM() field called type with following values possible: internal, deposit, withdrawal)
Please note that I have already a table logs to store every user action.
Unfortunately, I feel that my design approch is not the best possible in this aspect. Can you share some ideas/tips?
PS. Can I use a name "escrow" for internal payments or should I choose different name?
Edit
DEPOSITS, PAYMENTS and WITHDRAWALS tables store specific transaction details. TRANSACTIONS table stores only limited info - it's a kind of logs table - with a details field (which contains a text to display in user log section, ex: "User 1 sent you a payment for something")/
Of course I have users tables, etc.
Can I use a name "escrow" for internal
payments or should I choose different
name?
Escrow has a specfic financial/legal meaning, which is different from how you seem to mean it: "a written agreement (or property or money) delivered to a third party or put in trust by one party to a contract to be returned after fulfillment of some condition" (source)
So choosing a different name seems like a good idea.
As for design, what data will DEPOSITS, PAYMENTS and WITHDRAWALS store which TRANSACTIONS won't? Also, you need an ACCOUNTS table. Or are you planning to just use your existing USERS table (I presume you have such a thing)? You probably ought to have something for external parties, even if you only intend to support PayPal for the time being.
What is the general pattern or approach to managing transactions in a web-based e-commerce system? How do you handle the situation where more than one user tries to buy the last item, for example?
To prevent two users from purchasing the same stock item of which there is only 1 unit in stock, you need to check that each item in a user's cart has stock available right before you create an order and decrement stock for that item.
This operation will have to be atomic and only one order can be processed at any given time (read: database transaction), which should not be a problem if you are using a central database for stock management.
If stock has run out by the time a client checks out, you should remove the item from the client's cart and redirect them to their shopping cart, informing them of the situation.
Of course, this situation only occurs when two users both add the same stock item to their cart of which only one unit is in stock and one of them checks out. First come, first served. You should generally not allow clients to add products to their cart if no stock is available at that moment, unless you can order new stock within a reasonable amount of time, but in that case, the whole point is moot.
You can take a preemptive approach by checking that stock is available the moment a client initiates checkout and take the same route as above. However, that would depend on the nature of your product and the volume of transactions vs cancelled orders. If it is likely that another order for the same item was cancelled in the meantime and stock becomes available by the time a client checks out, then you don't want to lose a sale by telling the client that no stock is available. Better to let the order fail at the moment stock is not available and inform the client of the situation, which is rare after all.
Why not take the order and then get that item for the customer, perhaps a bit later? You can win a repeat customer :)