Deleting an object in your Backendless Database using the Data Service API is just as easy as creating or updating one. If an object has relations, they are broken up and the related objects are not deleted. The sample below retrieves the first object from a table and deletes it.
There will often be times when you want to delete users from your database, whether it’s to purge old users or to allow users to delete their own account. Backendless supports two methods for deleting a user: using the API or using Backendless Console. The API approach is described using the code below.
There is an API for loading the very first object created in the table. The first object is determined by the value in the created column – Backendless Database picks the one with the smallest timestamp.
Data paging is the process of breaking up a larger set of objects into smaller chunks, commonly referred to as pages. Typically paging applies to the results of search queries when the server may return too many objects at once.
Data objects stored in Backendless Database may have related objects through one-to-one or one-to-many collections. When objects are retrieved on the client-side, these relations are materialized as collections of data in the object’s fields or properties.
There may be instances where you need to create a user manually in your database rather than through your application. Whenever you need to quickly create a user for your app, you can always use Backendless Console. The Console makes the user creation process simple. This approach requires no coding at all, and the created…
The article that shows how to store objects in Backendless also demonstrated dynamic data table creation. That approach is called “code first” – where the code dictates the database schema.
In another post, we showed how to update data objects in the persistent storage. In this post, we’ll talk about declaring the minimum required properties needed to update objects.
In this post, we will show how to save an object with relations in Backendless Database. We are using the “code first” approach, which means we will not be creating data tables in the backend. Instead, the code will dictate to the backend what the data schema should look like.