limitations on Field names about sugar HOT 17 OPEN

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

from sugar.

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);

from sugar.

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.

from sugar.

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

from sugar.

thanks.

from sugar.

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;
      } 
}

from sugar.

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.

from sugar.

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.

from sugar.

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

from sugar.

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!

from sugar.

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 ?

from sugar.

Is there any update ?

from sugar.

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.

from sugar.

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

from sugar.

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

from sugar.

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.

from sugar.

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

from sugar.