I want to define an intent PlaceReservation that would capture a restaurant reservation. The parameters for that would be numOfPeople and time. Both of those parameters are optional, so a user can say:
get a table for 5 people for 9pm
get a table for 5 people
get a table for 9pm
get a table
get a table for 5
get a table for 9pm for 5 people
get a table for 5 for 9pm
My problem is with the last one, get a table for 5 for 9pm the intent then captures 5 as the hour (5am) and ignores 9pm.
time is defined as a #sys.time system entity.
Is there a way to tell it to not accept simple integers as time, as I think this is what is confusing it?
Is there some other solution I'm missing?
I certainly understand why it is making the mistake, but we, as humans understand how to interpret it, and I want to help DialogFlow interpret it accordingly.
I've had a similar problem and haven't found a proper solution for it yet. In your case you could define your own time entity that consists of entries like 9pm or 10am or even expand it with a composite entity to also let users say "10 in the morning" https://dialogflow.com/docs/entities#dev_composite.
This is definitely confusing for the bot to understand/interpret which one is time & which one is the number of people. Even creating a separate entity for time like 9am/10am won't work cause this does not guarantee that user will enter 9am/pm only. They may not append am/pm ahead of time as well. The solution to your problem can be creating separate intents, first asking users for time & then for number of people. This way you reduce the complexity & can train the bot in a proper way. In addition, you can direct user to a certain direction instead of keeping your bot open for questions.
Related
I currently have a coreData entity called CalorieProgress, which I would like to reset all variables (calorieProgress, fatProgress) to 0, every day.
I am still quite new to SwiftUI, and the only method I thought of as of now, is to add a Date Created variable to this entity called created, and when the user opens the app, to check if that date was yesterday. If so set all values to 0 etc.
Is there a more efficient way to do this?
Thanks
Your design is good and simple, and a reasonable choice if you're getting started.
It can have trouble, however, when people move between time zones. It is even possible for people to move to previous days this way (most dramatically when they cross the date line). There is no single answer to that question. Your app has to decide what it means by "today" when strange clock events happen. (Users also sometimes change their clock, and you want to behave "reasonably" in those cases, even if it means the data is wrong.)
Having built several of these, my suggestion is to just store raw, immutable, data records, and work out things like resetting values when you're running queries. For example, to work out how many calories someone has burned "today" doesn't require that you set any value to zero. You can just perform a query for records that occur after some time and sum their calories (you can even do this with aggregate queries directly on Core Data).
Core Data can be very fast, but if these queries become too slow, you can store daily aggregation records in Core Data. But keeping the original raw data means that those are really just caches and you can throw them away and recompute any time you need to.
Assuming that a new day starts as midnight (I've worked on apps where days started "when the user wakes up in the morning" which is much more complicated...) you should also be aware of significantTimeChangeNotification which is posted at midnight (and a few other times). You can't use this to launch your app or do processing in the background, but it's very nice for updating your UI if the user has the app open.
I am trying to implement a method where a post(s) will be deleted after a given time frame. In my case 10 weeks.
How would I go about implementing a feature? I've read that Firebase does not support server-sided scripting. So how could I go about it? When users uploads a post, I do have a timestamp node attached. Is it a case of comparing the post's timestamp to a timestamp of 10 weeks? And then removing the post? Or is there another, more efficient way to achieve such a thing?
If I was to implement the aforementioned method, this would mean I'd require an observer/method to first analyse ALL posts, then do the comparison and then execute the second phase, depending on the timestamp - removeValue or simply return. And I wouldn't I need to use NotificatonCenter so I can call this code throughout my whole app?
Any input/advice would be appreciated.
I have a task to create a database to track student results in a school. I came out with a set of relationships between the tables according to the 3 forms of normalisation(I hope I got it right. If not, please enlighten me).
One feature that I want to put in the Filemaker app is that when a teacher want to enter some assignment marks, he will just need to create a new submission record and all the student names in the class will appear.
I could not think how this feature can be done in Filemaker. I can only create a new submissions record and key in a student's score, then create another new record to do the same thing for a second student.
Can someone help? I am a teacher, not a Filemaker developer so please correct me if my database tables are done wrongly.
Update:
I will like the output to be like this
Spreadsheet is not suitable because it can't be used to search/sort easily.
I have a quick sample file here. It's an old sample and it uses a different (but similar) model. Basically the idea is that: You have a calculated field (I use a repeating field) to display the data. You also have a global repeating field that serves as an editing widget. Each time you go to a record you fill this field's reps with data from related records (using a OnRecordLoad trigger). This doesn't mean the field shows the same data for all records, because its conditional formatting rules are set to hide all data; so it only shows a piece of data when you actually enter one of its repetitions. This is the data that can be edited. And finally there's a trigger that fires each time you exit the field and posts your changes to the related table (adds, updates, or deletes).
The sample isn't quite complete because if there's fewer data columns than repetitions, you'd probably want to somehow lock the remaining repetitions; this part isn't done. Otherwise it works fairly well. In FM 12, however, it tends to freeze the app; I reported this to FMI, they acknowledged it, but I don't think it has been fixed already.
I have company website, with many offices around the world (around 50 offices).
The company want to create a gift giveaway with the employees in a specific company each specific day.
For example:
Office 1: will do the giveaway the days: 1/1/2010, 7/1/2010, 15/1/2010, etc...
Office 2: the days: 2/1/2010, 9/1/2010, 19/1/2010, etc...
Office 3: ....
Office 50: ...
(the days are setup manually to specific offices, no need of an algorithm here)
I have a node per Office, it's a CCK content type with details of each office (location, phone, email, etc), now I need to assign those days to the offices.
But my problem here is that I don't need to create events (or at least node events) because I don't need to store any data in the event. Just need to say: Office 1? Yes, days 1/1/2010, 7/1/2010, etc...
Nothing else, just to know the dates.
And, if possible, make them available to display in the calendar module.
What is your suggestion?
Withs CCK and date module you can create date fields, but if you have many fields you want to add, this might not be the best solution.
You have two general ways of solving this issue. Either you need store each date. This could be done with date field, not sure if it can handle multiple values, node reference or similar. This is inefective it some ways, but will make it easy to generate calendar view.
You could also write a string with as the date info and let php convert it to dates. This route will make it easier to create and store the data, but will make it a lot harder to get things integrated with calendar.
The fatest / easiest solution would probably be node reference with a date module, combined with a script to create all the nodes need. Instead of making them inside Drupal.
You could also create a custom module that stores this info for you. It would be a more longterm solution and require more work to integrate it with views and date/calendar modules.
There are many ways to go about this, but it really depends on your need, skill and time
Why not use a plain old CCK text field with a good clear description of what it's for and how to format it with something in the help section to back it up?
Use a text area (multiple rows) and apply the default input format that converts lines line breaks. I like to use the mark down filter too.
You could also use multiple single line fields in place of a text area...
This assumes your users are smart enough to enter the correct info of course but that's what the help and description are for. If your users can't be trusted to enter the content in correctly then yes, go for something that forces them to do so.
Ok I've found the solution myself and I want to share it with you:
Created three content types:
Office: with data of the office
Days: with a node per day (365 * year)
and Giveaway: with two node-reference fields, one for Office and another for Day.
(Days must be populated manually using a script that fills the upcoming 2 years or so).
So I can fill only Giveaway content type, and that's enough.
And then only the views are remaining.
I keep seeing questions floating through that make reference to a column in a database table named something like DateLastUpdated. I don't get it.
The only companion field I've ever seen is LastUpdateUserId or such. There's never an indicator about why the update took place; or even what the update was.
On top of that, this field is sometimes written from within a trigger, where even less context is available.
It certainly doesn't even come close to being an audit trail; so that can't be the justification. And if there is and audit trail somewhere in a log or whatever, this field would be redundant.
What am I missing? Why is this pattern so popular?
Such a field can be used to detect whether there are conflicting edits made by different processes. When you retrieve a record from the database, you get the previous DateLastUpdated field. After making changes to other fields, you submit the record back to the database layer. The database layer checks that the DateLastUpdated you submit matches the one still in the database. If it matches, then the update is performed (and DateLastUpdated is updated to the current time). However, if it does not match, then some other process has changed the record in the meantime and the current update can be aborted.
It depends on the exact circumstance, but a timestamp like that can be very useful for autogenerated data - you can figure out if something needs to be recalculated if a depedency has changed later on (this is how build systems calculate which files need to be recompiled).
Also, many websites will have data marking "Last changed" on a page, particularly news sites that may edit content. The exact reason isn't necessary (and there likely exist backups in case an audit trail is really necessary), but this data needs to be visible to the end user.
These sorts of things are typically used for business applications where user action is required to initiate the update. Typically, there will be some kind of business app (eg a CRM desktop application) and for most updates there tends to be only one way of making the update.
If you're looking at address data, that was done through the "Maintain Address" screen, etc.
Such database auditing is there to augment business-level auditing, not to replace it. Call centres will sometimes (or always in the case of financial services providers in Australia, as one example) record phone calls. That's part of the audit trail too but doesn't tend to be part of the IT solution as far as the desktop application (and related infrastructure) goes, although that is by no means a hard and fast rule.
Call centre staff will also typically have some sort of "Notes" or "Log" functionality where they can type freeform text as to why the customer called and what action was taken so the next operator can pick up where they left off when the customer rings back.
Triggers will often be used to record exactly what was changed (eg writing the old record to an audit table). The purpose of all this is that with all the information (the notes, recorded call, database audit trail and logs) the previous state of the data can be reconstructed as can the resulting action. This may be to find/resolve bugs in the system or simply as a conflict resolution process with the customer.
It is certainly popular - rails for example has a shorthand for it, as well as a creation timestamp (:timestamps).
At the application level it's very useful, as the same pattern is very common in views - look at the questions here for example (answered 56 secs ago, etc).
It can also be used retrospectively in reporting to generate stats (e.g. what is the growth curve of the number of records in the DB).
there are a couple of scenarios
Let's say you have an address table for your customers
you have your CRM app, the customer calls that his address has changed a month ago, with the LastUpdate column you can see that this row for this customer hasn't been touched in 4 months
usually you use triggers to populate a history table so that you can see all the other history, if you see that the creationdate and updated date are the same there is no point hitting the history table since you won't find anything
you calculate indexes (stock market), you can easily see that it was recalculated just by looking at this column
there are 2 DB servers, by comparing the date column you can find out if all the changes have been replicated or not etc etc ect
This is also very useful if you have to send feeds out to clients that are delta feeds, that is only the records that have been changed or inserted since the data of the last feed are sent.