@property
stuff. I'm not well versed in obj-c at all, what does that change do?
List
s should also be Collection
s though, since List extends Collection. I'll probably need to examine the translated code and do some debug stepping to track down the problem
InCollectionCriterion
to make sure it's adding your argument as a collection, and also add some logging to the private findCollectionArgs
method in CompiledArgumentResolver
to see if that is in turn finding your collection args.
findCollectionArgs
looks through the argument list for anything that's a collection, and adds it to the collectionArgs
field in CompiledArgumentResolver
. line 94 in that class extracts them: Collection<?> values = collectionArgs.get(index);
, but the exception indicates the list is empty. it'll be illuminating to understand why it's empty
@MFlisar you can mark fields in your model spec with @Deprecated
. this will have the following effects:
1) the column will no longer be included in any newly created tables (but as you say will still exist in existing ones)
2) no getter or setter will be generated in the model for the column
3) a corresponding @Deprecated
property for the column will still be generated in the model spec, to assist in writing database migrations using that column
validation to protect you from reintroducing the column name later isn't part of this -- I can definitely imagine a scenario where users might want to repurpose or undeprecate a column using e.g. a different type, so I would be hesitant to have forbidding that be the default. but you could easily implement such validation yourself using a code generation plugin that scans your list of regular and deprecated properties to look for any name duplications
Of course it would be nice to only optionally makr a field name as unusable like @Deprecated(reuseageAllow = false)
or similar. Actually, because of different column type this would be nice. Consider having a column used with an int value, then you deprecate it and half a year later you introduce a new column with the same name but a string value. Tests won't show you any errors, you make a new release and get crashes because of missmatching column types.
In this case it would be nice to get an information that the column name may already exist on some users device so that I can change @Deprecated(reuseageAllow = false)
to @Deprecated
and make sure that I write the correct migration code - in this case I would have to delete the old column via a temp intermediate table.
Currently I prefer using following alternative solution that solves this problem over using @Deprecated
:
// renaming the field and use the old olumn name
// to make sure to get duplication errors in generated code if the name is reused
@ColumnSpec(name = "name")
String _deprecated1;
Just because this way I get an exception in database creation because of duplicate field names. So testing my app in the emulator will immediately show me that I have a problem...
Still I would prefer an annotation processor exception instead, it should check if a field name and a deprecated field name with reuseageAllow = false
exists and throw a generation error... Imho, this would be very nice and would help improving safety...
@Deprecated(reusageAllow = false)
would require a custom @Deprecated
annotation that would shadow the default Java one which might not be great, but we could name it something else. although, you might have convinced me -- disallowing reusing a name as the default might not be so bad, because you could always get around it by simply removing the deprecated column altogether and fully replacing it with your new one. you'd have to be careful with your migrations in such a case, but you could do it. as I mentioned I haven't had time for much active development lately, but we've been introducing a lot more compile time code validation in the 4.0 dev branch so I could look into adding it there, and as I mentioned a simple code generation plugin would also definitely work
new_procedure
()public SquidCursor<User> getUsers(int minimumAge) {
// Equivalent to select * from users where users.age >= minimumAge
return mySquidDatabase.query(User.class, Query.select().where(User.AGE.gte(minimumAge)));
}
SquidDatabase