limitations on Field names

[timmer3]

hi, i'm new to android development and finding the sugar library very helpful. a few things tripped me up starting off:

one of my data classes had fields for Address1, Address2, Address3, Address4.
when it came down to running the app the sugar library traced out some exceptions re: duplicate field names for ADDRESS. i changed the names to AddressOne, AddressTwo etc and there was no problem.

i also had an Integer field called ID. this conflicted with the internal Sugar 'id' field, so i had to rename this to ServerID. no problem then.

another field called RollNumber didn't work. i had to rename it to "Roll" instead and it worked. maybe the 'Number' got stripped out...

great library, thanks.
tim

[satyan]

Thanks for sharing the details.. Except for 'Id' other fields need to work. I'll be looking into them.

[timmer3]

I noticed the StringUtil.toSQLName method puts in underscores for CamelCased column names. this makes it difficult when using Where filters as string literals, e.g. i have a class with a String property KeyName, the where filter "KeyName = ?", won't work because internally the field has been mapped to KEY_NAME. would it be more usef-friendly to keep the field names the same as their coded equivalents, and make sure that none of the properties violate SqLite naming conventions? given that the string literal searches are the one weakness of an ORM like this, i think it would make it more robust.

on another note, here's a useful method mimicing the FirstOrDefault implentation from the C# / Linq world, enabling search for one record only without fetching the entire list (if the internal findById is not useful)

SugarRecord.Java:

public static <T extends SugarRecord> T findFirst(Class<T> type, String query, String... arguments){
     Database db = getSugarContext().database;
     SQLiteDatabase sqLiteDatabase = db.openDB();
     Cursor c = sqLiteDatabase.query(getTableName(type), null,
             query, arguments, null, null, null, null);
     try {
         if(c.moveToNext()) {
             T entity = type.getDeclaredConstructor(Context.class).newInstance(getSugarContext());
             entity.inflate(c);
             return entity;
         }
     } catch (Exception e) {
         e.printStackTrace();
     } finally {
         c.close();
     }
     return null;   // entity not found
}

sample usage:

DbOption o = DbOption.firstOrDefault(DbOption.class, "KEY_NAME = ?", "Event");
if(o != null)
txt.setText(o.KeyValue);

[satyan]

To your first suggestion, I'm probably thinking of it as a configuration option. Something that a user can override too, or provide his/her own implementation. Yeah, at times it can get confusing.

On the second one, yes. Will add that in SugarRecord. There are few other utilities too.. like count, countBy, etc. that I was thinking.

[timmer3]

brilliant. i can't tell you how glad i was to find this library, it's a great piece of work. thank you.

[satyan]

thanks.

[timmer3]

useful addition to the SugarRecord class, just posting here while i have it:

public static <T extends SugarRecord> long Count(Class<T> type){
    return Count(type, null, new String[]{});
}

public static <T extends SugarRecord> long Count(Class<T> type, String query){
    return Count(type, query, new String[]{});
}

public static <T extends SugarRecord> long Count(Class<T> type, String query, String... arguments){
     Database db = getSugarContext().database;
     SQLiteDatabase sqLiteDatabase = db.openDB();
     String table = getTableName(type);
     try {
      return DatabaseUtils.queryNumEntries(sqLiteDatabase, table, query, arguments);         
      } catch (Exception e) {
          e.printStackTrace();
          return -1;
      } 
}

[gipi]

Another problem is field names conflicting with keyword of SQL: for example I have a class with a group String property that causes the following exception:

android.database.sqlite.SQLiteException: near "GROUP": syntax error (code 1): , while compiling: CREATE TABLE STATUS_SPEDIZIONE ( ID INTEGER PRIMARY KEY AUTOINCREMENT , GROUP TEXT)

I think should be a mapping between original and mangled field names so to be reused also in the search methods.

[jturolla]

ORDER meaning "purchase" conflicted in my project.

Please create a conflict filter or an exception for that... I spent 2 hours trying to figure this out.

[whoshuu]

@jturolla, please refer to issue #98. There will be automatic filtering of SQL keywords in a to-be-determined future release.

[duduBaiao]

Hi guys!

My REST service returns JSON objects that already has attributes named "ID", so my local database is only a cache for data that already exists on the server database.

Can I still use Sugar?

I need that the ORM do not automatically generate ID values and, as my IDs are very long integers, I also need to define their type to BigInteger.

Is that possible?

Thanks!

[shuja-zaka-khan]

I am facing the same problem as duduBaiao. i,e
"My REST service returns JSON objects that already has attributes named "ID", so my local database is only a cache for data that already exists on the server database.

Can I still use Sugar?

I need that the ORM do not automatically generate ID values and, as my IDs are very long integers, I also need to define their type to BigInteger."

Is there any solution for it ?

[shuja-zaka-khan]

Is there any update ?

[whoshuu]

The upcoming release 1.4.0 will have support for user specified ID's being used in the database instead of having them generated automatically.

[shuja-zaka-khan]

Good to hear that. When do we expect release 1.4.0 ?

[whoshuu]

Hoping to get it released by the end of April, but don't quote me on that 😛

[ghost]

Hi guys! I've got started with Sugar ORM and I think it's super easy to use, works well and saves a lot of time. I want to use this library in two projects already, but I face the same problem than other devs here. I have an api server, so the objects I want to save already have an id, being a limitation that the primary key strategy is not configurable. Is there any status around that feature?

We could rename the SugarRecord id member to sugarId and everyone would be happy or we could make the primary key generation strategy configurable.

I am pretty happy to help. Thank you.

[shuja-zaka-khan]

The upcoming release 1.4.0
https://github.com/satyan/sugar/milestones/1.4.0 have this listed in the
milestones.