Search Results

Search found 4 results on 1 pages for 'ormlite'.

Page 1/1 | 1 

• Android/ORMLite Insert Row with ID

  - by Joe M

  I'm currently using ORMLite to work with a SQLite database on Android. As part of this I am downloading a bunch of data from a backend server and I'd like to have this data added to the SQLite database in the exact same format it is on the backend server (ie the IDs are the same, etc). So, my question to you is if I populate my database entry object (we'll call it Equipment), including Equipment's generatedId/primary key field via setId(), and I then run a DAO.create() with that Equipment entry will that ID be saved correctly? I tried it this way and it seems to me that this was not the case. If that is the case I will try again and look for other problems, but with the first few passes over the code I was not able to find one. So essentially, if I call DAO.create() on a database object with an ID set will that ID be sent to the database and if it is not, how can I insert a row with a primary key value already filled out? Thanks!

  Read the article

• Is it possible to have an enum field in a class persisted with OrmLite?

  - by htf

  Hello. I'm trying to persist the following class with OrmLite: public class Field { @DatabaseField(id = true) public String name; @DatabaseField(canBeNull = false) public FieldType type; public Field() { } } The FieldType is a public enum. The field, corresponding to the type is string in SQLite (is doesn't support enums). When I try to use it, I get the following exception: INFO [main] (SingleConnectionDataSource.java:244) - Established shared JDBC Connection: org.sqlite.Conn@5224ee Exception in thread "main" org.springframework.beans.factory.BeanInitializationException: Initialization of DAO failed; nested exception is java.lang.IllegalArgumentException: Unknown field class class enums.FieldType for field FieldType:name=type,class=class orm.Field at org.springframework.dao.support.DaoSupport.afterPropertiesSet(DaoSupport.java:51) at orm.FieldDAO.getInstance(FieldDAO.java:17) at orm.Field.fromString(Field.java:23) at orm.Field.main(Field.java:38) Caused by: java.lang.IllegalArgumentException: Unknown field class class enums.FieldType for field FieldType:name=type,class=class orm.Field at com.j256.ormlite.field.FieldType.<init>(FieldType.java:54) at com.j256.ormlite.field.FieldType.createFieldType(FieldType.java:381) at com.j256.ormlite.table.DatabaseTableConfig.fromClass(DatabaseTableConfig.java:82) at com.j256.ormlite.dao.BaseJdbcDao.initDao(BaseJdbcDao.java:116) at org.springframework.dao.support.DaoSupport.afterPropertiesSet(DaoSupport.java:48) ... 3 more So how do I tell OrmLite, values on the Java side are from an enum?

  Read the article

• Sharing code between sqlite-net and servicestack ormlite?

  - by lanks

  I am using sqlite-net to store data on my MonoDroid mobile application. I am wanting to sync this data with a server side service as well. Would it be possible to share the code for my Entity objects between sqlite-net and Servicestacks ormlite? The main difference between the two that I can see is declaring the "using namespace" statements at the top of the class for the object. Is it possible to detect the platform and set the using statements based on the platform? The other difference would be referencing the different dlls for servicestack so I suppose on the mobile app it would not compile if there are references to the servicestack namespaces... What would a good approach be to achieve sharing of this code?

  Read the article

• Does it make sense to use ORM in Android development?

  - by Heinzi

  Does it make sense to use an ORM in Android development or is the framework optimized for a tighter coupling between the UI and the DB layer? Background: I've just started with Android development, and my first instinct (coming from a .net background) was to look for a small object-relational mapper and other tools that help reduce boilerplate clode (e.g. POJOs + OrmLite + Lombok). However, while developing my first toy application I stumbled upon a UI class that explicitly requires a database cursor: AlphabetIndexer. That made me wonder if maybe the Android library is not suited for a strict decoupling of UI and DB layer and that I will miss out on a lot of useful, time-saving features if I try to use POJOs everywhere (instead of direct database access). Clarification: I'm quite aware of the advantages of using ORM in general, I'm specifically interested in how well the Android class library plays along with it.

  Read the article

1