I didn’t find in the documentation an API call to check if a table exists.
At the moment i’m using this:
private <T> boolean exists(Class<T> clazz) {
String simpleName = Persistence.getSimpleName(clazz);
try {
Backendless.Persistence.describe(simpleName);
return true;
} catch (NullPointerException ex) {
return false;
}
}
Maybe an API call would be more effective than a try/catch.
Hi Mihai,
As long as our SDK for Java/Android is purely object-oriented, it seems to me that we don’t provide a direct method to check whether the table exists. You can work with the data objects without this knowledge - the tables will be created implicitly when you save a new data object.
Could you please clarify in which cases you need such functionality?
Hi Sergey,
I’m hybrid app - Parse login (and other Parse features - go figure) and a mysql database - to Backendless.
User data is not stored in the BackendlessUser object, but another class - User. I prefer to use getters/setters instead of getProperty.
When a user registers, i first check if it already exists in the User table.
If the table was not created manually the query to find existing users fails:
Backendless.Persistence.of(User.class).find(query); //throws exception
with this stacktrace:
BackendlessException{ code: 'Internal client exception', message: 'weborb.reader.NullType cannot be cast to weborb.reader.NamedObject' }
at com.backendless.Invoker$SyncResponder.errorHandler(Invoker.java:127)
at com.backendless.core.responder.AdaptingResponder.errorHandler(AdaptingResponder.java:93)
at weborb.client.ioEngine.HttpIOEngine.send(HttpIOEngine.java:213)
at weborb.client.ioEngine.HttpIOEngine.invoke(HttpIOEngine.java:145)
at weborb.client.WeborbClient.invoke(WeborbClient.java:138)
at com.backendless.Invoker.invokeSync(Invoker.java:100)
at com.backendless.Persistence.find(Persistence.java:589)
at com.backendless.DataStoreFactory$1.find(DataStoreFactory.java:161)
at dao.UserDao.findUserByEmail(UserDao.java:40)
at dao.UserDao.getUserByEmail(UserDao.java:28)
at bo.UserBo.getUserByEmail(UserBo.java:23)
at controllers.Service.register(Service.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at weborb.util.Invocation.invoke(Invocation.java:190)
at weborb.util.Invocation.invoke(Invocation.java:62)
at com.backendless.coderunner.runtime.task.ServiceInvocationTask.runImpl(ServiceInvocationTask.java:92)
at com.backendless.coderunner.runtime.concurrent.ExtendedRunnable.run(ExtendedRunnable.java:22)
at java.lang.Thread.run(Thread.java:745)
Long story short => a query on a table that does not exist, throws an exception.
I wanted make things a little bit automated so i don’t have to create the table manually if it was deleted.
What’s wrong about creating that table ONCE in console and just be done with that problem?
Nothing wrong.
But the app is still in development, and things change… it’s easier to delete a table and recreate it automatically when adding a user, than manually creating a schema.
I must be missing something… Why would you delete a table if your app needs it?
But you can’t delete a table from your code. So if someone removes it using developer’s console, it’s pretty easy to recreate it immediately after.
Maybe my use case is not the best example.
Yesterday i had the User class/table with some properties.
Today because of forces beyond my control, those properties change, some new ones are added, others are removed.
During development, it’s easier to just the delete a table from the Console.
I’ve just tried Sergey’s idea: delete the table, and create it again without editing the schema.
It’s flawless.
Thank you both for your support.
Glad it helped!
And yes, you don’t need to edit schema after creation, as the columns will also be created implicitly according to the properties of your User class when your save it.
@Mihai, I’m coming across the same use case as you. Did you basically create the table manually or did you figure out a way to check if the table exist programmatically?
Maintaining your users in another table is a very bad idea for the following reasons:
You lose support for the registration API
You lose support for the login API
You lose social login support (Facebook, Twitter, Google+)
You cannot assign roles to users
You lose user/roles-based security
To check if schema exists, you can use this call:
https://backendless.com/documentation/data/rest/data_retrieving_properties_of_the_d.htm
If you get an error, the table does not exist