I have a Watson bot i'm trying to program for reserving tables. I'd like to know the expression I could use to implement my opening times.
For example the restaurant has the following hours:
Monday-Friday 11:30AM until 10:30PM, last reservation can is 9:30PM.
Saturday-Sunday 5PM until 10:30PM
I don't want Watson to take reservations outside those hours. How code I implement this in slots?
You can use methods of the expession language to evaluate the input.
For example a condition to check if it is a valid weekday reservation could be :
#sys-date.reformatDateTime('u')<6 AND #sys-time.before('21:30:01') AND #sys-time.after('11:29:59')
I would not recommend to to do the check in slots.
Easier would be to do the check after slot-filling.
If it is no valid reservation you can offer the client to just try again.
I don't think there's any way to do this in Watson Assistant directly. You can do conditional evaluation (check if a number if greater than or less than another number), but your needs are a little more complex (with time involved, and even dates too).
I'd suggest handling your reservation validation process externally using the webhook feature. Collect your reservation date and time, and then send those to your webhook as parameters. The webhook can then respond with a confirmation that the reservation is OK, or it could reject it (and provide a reason). When your dialog node that calls the webhook gets the response, if it sees a rejection based on operating hours, it could inform the user that they need to select a time that the restaurant is open, remind them of the hours, and then go back to the node that collects the reservation info.
I'm using CouchDB for syncing offline and online data. The problem is that since couchDB hasn't a layer between client and server, validation is kinda poor. The only field that can be unique is the _id.
For example if you want to make a sure the field "phone" is unique, you need to make sure that the phone number is somewhere in the _id (555-666-777_username) and the field "phone" is 555-666-777.
My problem is: I have a calendar that makes events that cannot overlap each other. An event has a start time and an end time. How can I make sure that the user won't put a date between the start time and end time.
One idea is instead of making one document with a startTime and endTime. It's to make various documents that have dates within the user's desired range.
Example: User selects a range between 2018-09-02 and 2018-09-10, so I'll create 8 documents with a _id composed of {date}{username}.
If you think couchDB doesn't suit to this kind of stuff, I'm open for suggestions.
How can I do watson conversation to ignore a number written in a sentence don't converting to #sys-number?
Ex.: I want to give you A call.
In the case, the Watson understends 'A' with '1'. But I don't have this.
When you're using this example to send the message, Watson Conversation shown to you what they understand (Intent, entities, etc).
You can use .literal method and show the number in the cardinal form, and you can use the #sys-number for getting this number in another answer, or in your application with one custom code.
Example:
I want to give you #sys-number.literal call.
In this case, you can check in this table how System entity #sys-number works:
Obs.: You can disable the #sys-number inside the System Entities and Watson won't try to identify the number inside your Conversation.
See the Official documentation talking about System Entities within Watson Conversation.
I am not seeing the same behavior. I have sys-number turned on but it is not matching to the letter A.
I would like to implement datetime ordered entity in appengine, pretty much like Appengine's own logs. So I probably will need some kind of unique ordered id generation algorithm.
Has anyone got any suggestion on this?
Having a similar need I passed a long integer time stamp as identifier to the Entity constructor. The identifier can be only a string or a long integer according to Java Datastore Entities, Properties, and Keys. In order to see the actual dates and times in the Datastore Viewer I put the same value converted to a java.util.Date into an unindexed property as well. Admittedly some denormalized redundancy but convenient in practice.
Use the date that you are appending. One way is to convert it to unix time (ms since 1970) so its numeric.
A better way but more code is to not use the datastore and use bigquery instead. Probably cheaper.
We need more informations about what you want to do.
If you want to make some logs, you can use timestamp indeed.
With python and ndb it's easy :
class Log(ndb.Model):
date = ndb.DateTimeProperty(auto_now_add=True)
message = ndb.StringProperty()
Then you order your logs by the date field.
If you want to make like AppEngine, you can link your log with a parent key and order by date and parent key.
AppEngine Python ndb
I hope it helped you.
I want to write a calendar application. It is really recurring items that throw a wrench in the works for the DB schema. I would love some input on how to organize this.
What if a user creates an event, and inputs that it repeats everyone Monday, forever? How could I store all that in the database? I can't create infinite events. Do I simply put a table in there that holds the relevant info so I can calculate where all the events go? If so, I would have to calculate them every time the user views a new part of the calendar. What if they page through the months, but they have a ton of recurring items?
Also, the schema needs to handle when a user clicks an item and says "Edit this one in the sequence" not all items in the sequence. Do I then split the one item off of the sequence?
Update 1
I have not looked at iCal at all. To be clear, I think saving the info that allows you to calculate the recurring items, and splitting off any that differ from the sequence is a great way to store it to be able to transfer it. But I think that in an application, this would be too slow, to do the date math all over the place.
I have been struggling with the same problem, and I was actually toying with the "cache table" idea suggested above, but then I came across an alternative (suggested here) that doesn't seem to have been represented yet.
Build a table containing all events
EventID (primary key)
Description
StartDate
PeriodType - days, weeks, months, years
PeriodFreq - # of days, weeks, etc between events
EndDate
... other attributes that can be modified
Then add a table for exceptions to these events. This table uses a composite key, made up of the EventID that maps to the event table, and an instance ID to pick the particular event in the series.
EventID (key)
InstanceID (key)
InstanceDate - the modified date of the exception
IsCancelled - a flag to skip this date when traversing the series
... other attributes that can be modified
It seems to keep the event table normalised, and avoids splitting up series to handle exceptions.
I recently created a calendar application and this was one of the many challenges that I faced.
I eventually came up with a semi hack-ish solution. I created an event_type column. In that column, I had either: daily, weekly, monthly, or yearly. I also had a start_date and an end_date columns. Everything else was handled in the actual backend code.
I never tried to split an event if a user edited only one event. It wasn't necessary in the situation. However, you could split an event by changing the end_date of the first, creating a new event with a new start_date and the end_date of the original, and finally, a new event for the one you just chose to edit. This process would end up creating 3 events.
Hack-ish, I know. I couldn't think of a clever way to handle this problem at the time.
Hold the recurring item in the events table as normal, but flagged as recurring with the appropriate start/ end dates.
If the user modifies a single instance of the appointment, just create a new event, perhaps with a 'parentId' equal to the recurring event's id.
Build logic that causes the calendar to override any recurring events on a particular day with events with matching parent IDs.
Your question about performance is basically the old speed vs. storage issue. I really don't think the calculation required would exceed the space requirement for storing so many appointments. Just read up on database optimization- indexing etc.
Could you bridge the two worlds with a "cache" table, in which you pre-compute the next X days worth of events?
So three tables:
recurring_event_specs
one_time_events
cached_recurring_events
For any part of the calendar within X days of today, your query will UNION one_time_events and cached_recurring_events.
Then you would only have to do on-the-fly date calculations if the user tried to look at a part of the calendar more than X days in the future. I imagine you could find a sane X that would cover the majority of normal use.
The cached_recurring_events table would need to be updated whenever a user adds a new recurring event -- and possibly once a day offline, by a cron-job/scheduled-task. But only on days when no new recurring event has been created.
Why not use Google Calendar as a database for this calendar application by relying on Google Calendar's API for storing and retrieving calendar events?
The Calendar API is a REST API that can be accessed through explicit HTTP calls; the API exposes most of the features available in the Google Calendar Web interface, so your calendar application can as much functionality as Google Calendar does (a lot of functionality!!!).
Your application need only implement OAuth 2.0 for Google APIs, which can be made easy using a single sign-on service like Auth0 to provide the appropriate access tokens. Then, your calendar application can use these tokens in conjunction with the Calendar API to provide seamless storage and retrieval of calendar events in a JSON format.
Users create events within their own "New Calendar." This calendar is shared with you in the form of a gmail account dedicated to this application - the application's gmail account.
Basically, Google Calendar becomes your database, whereby you can have the application's gmail account not only store all of your application's events, but also allow you to view and edit these events with an intuitive interface.
The best way to do this is to store a standards based recurrence pattern string (iCal).. and leave blank if it's a single event. There are a few APIs that can parse the recurrence pattern and create event objects that you can bind to UI elements.... none of the occurrences need ever be stored in the database, only the initial event (occurrence)..
Couldn't you store the events per day with start and end time? It will generate a lot of data for events that happen everyday (maybe go non-relational for this) but it will make querying easier and it will be possible to make exceptions (f.e. the event place burned down, or employees are striking). To generate the days for the event I would suggest to implement that in the front-end derived on some ICal-ish pattern.