@MFlisar ah I see, I thought you were referring to the generated model method, not the generated getter. in that case your only option is a code generation plugin. if I understand what you're trying to do correctly, you'd probably want a custom subclass of
TableModelSpecFieldPlugin as well as custom subclasses of the BasicPropertyGenerator classes for different field types, i.e. BasicStringPropertyGenerator, BasicLongPropertyGenerator, etc. your custom property generator subclasses could look for specific annotations on their fields and override methods such as getterMethodName or writeGetterBody in order to customize the implementation details of your accessors. (at this time you can't skip generating getters/setters entirely, but you could you just design your annotations such that they caused the getter to delegate to a private model method, or you could make the getter name different and the method private). you'd need to register your custom property generator classes with your subclass of TableModelSpecFieldPlugin by overriding the methods such as getStringPropertyGenerator and getLongPropertyGenerator. hope that makes sense!
Hi Everyone! I'm working on integrating Kotlin into an existing Android application that uses SquiDB. All of our spec classes (e.g.
@TableModelSpec) are currently written in Java. When I try to use one of these classes from Kotlin I get a symbol not found error from the compiler. Issues #278 and #166 seem related. What I'm wondering is if this is a supported use-case in SquiDB? Or would we need to do something like port our existing spec classes to Kotlin and use kapt?
hi @sonelliot! I believe that you can keep your models in Java and just use
kapt -- while I haven't done much with kotlin myself, my understanding is that you just need to use that to configure both java and kotlin annotation processing when using the kotlin plugin. I think this is the same issue as #278 -- I just realized that a user submitted a pull request to clarify the readme for this issue that I missed, I should get that in :) hope that helps! definitely post back here if things still seem amiss
Hi Guys, is suqidb working with xcode 9? We tried and we found an issue when we use the in Criterion. It looks like it looses the collection of values. I double checked the list multiple times and it has values.
[ERROR] : Task - unobservedException Optional("Index: 0, Size: 0")
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 0x0000000102b20cc2 java.util.ArrayList.get() + 110
at 0x000000010328b9a2 com.yahoo.squidb.sql.CompiledArgumentResolver.resolveSqlString() + 610
at 0x000000010328b1b2 com.yahoo.squidb.sql.CompiledArgumentResolver.resolveToCompiledStatement() + 114
at 0x0000000103015ba5 com.yahoo.squidb.sql.TableStatement.compile() + 213
at 0x0000000103015c41 com.yahoo.squidb.sql.TableStatement.compile() + 33
at 0x000000010314d387 com.yahoo.squidb.data.SquidDatabase.query() + 119
at 0x00000001032d3ed5 co.thefabulous.shared.data.source.HabitRepository.getById() + 405
[ERROR] : Task - unobservedException Optional("Index: 0, Size: 0")
java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
at 0x0000000102b20cc2 java.util.ArrayList.get() + 110
at 0x000000010328b9a2 com.yahoo.squidb.sql.CompiledArgumentResolver.resolveSqlString() + 610
at 0x000000010328b1b2 com.yahoo.squidb.sql.CompiledArgumentResolver.resolveToCompiledStatement() + 114
at 0x0000000103015ba5 com.yahoo.squidb.sql.TableStatement.compile() + 213
at 0x0000000103015c41 com.yahoo.squidb.sql.TableStatement.compile() + 33
at 0x000000010314d387 com.yahoo.squidb.data.SquidDatabase.query() + 119
at 0x00000001032d3ed5 co.thefabulous.shared.data.source.HabitRepository.getById() + 405
based on the exception, I'd guess that when the arguments to the statement are resolved, the argument in the
in Criterion does not return true for instanceof java.util.Collection<?>. can you provide a brief code sample for how you're constructing the in Criterion? might help us to track down if there's some kind of bug with how j2objc translates things (I'm assuming this issue doesn't happen in java)
We had to change the ios native files to make it work
(some missing @property(copy))
ok, thanks! I've made some changes for j2objc 2.x on our dev_4.0 branch but have not tested with any versions of j2objc after 1.3.1. unfortunately I don't have access to a dev environment right now (moving this weekend and all my real computers are packed up) but I can take a closer look on monday
what were the
@property changes you needed to make? I don't think I encountered those when I was experimenting with j2objc 2
We create the Criterion in a very simple manner:
public List<Habit> getById(List<String> ids) {
SquidCursor<Habit> cur = db.query(Habit.class, Query.select(Habit.PROPERTIES).where(Habit.UID.in(ids)));
return habitCursorToList(cur);
}
thanks for the heads up about the
@property stuff. I'm not well versed in obj-c at all, what does that change do?
I'm assuming that it copies the values when assigning them but that seems like an odd necessity for strings, since strings should be immutable
I used copy just to make it work, not sure about it though
I wonder if that's a new thing in Xcode 9 that they introduced to guard against exactly that kind of bug. I'll definitely get those changes into our 4.0 branch
all
Lists should also be Collections though, since List extends Collection. I'll probably need to examine the translated code and do some debug stepping to track down the problem
if you would like to debug on your own before I can look at it on monday, you could add some logging to
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.
thanks!
if the logging doesn't reveal anything interesting about whether or not things are collections, I could be way off in my guess :) but based on the exception that's what it seems like.
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
I'm sure your list has arguments, but it seems like the list of lists that we keep internally isn't being populated, and that's what's throwing the exception
@aminelaadhari I just came across this: https://groups.google.com/forum/#!topic/j2objc-discuss/avy79pz1XxU/discussion. not sure if its the same issue, but it sounds similar to what you're experiencing
notable comment: "I'm seeing this too, with our use of translated gson. In our case java.util.Collection.isAssignableFrom(java.util.List) returns false"
the general conclusion of that thread seems to be that it's probably a swift compiler bug (are you using swift in your project)? the thread also suggests some workarounds that you could experiment with
I will try the workaround now
Hi everyone ! I'm interested by SquiDB for a cross platform dev and would like to know if a ModelSpec class can extends another class that contains common fields used by many tables like ids, creation and update dates and creation and update authors. I need these fields in almost all my tables (around 30 in total) and would like to avoid the copy paste :) I have tried to extend class but generator don't take it in count and didn't find anything in code about that point... Thanks !
hey @WizzCad, great question. unfortunately we don't have first class support for that at the moment -- it's been on my radar to add to 4.0 for a long time, but I've sadly had very little time for active development lately. I would suggest the following as a workaround -- if it's always the same collection of columns that you're wanting to use in all your models, you could create a code generation plugin for those columns at compile time and add them into the code generator's internal representation of the model spec so they all get picked up and generated. you might even be able to make a code generation plugin to scan a superclass of a model spec (which is what we'd eventually do when adding first-class support for this), although it would be a bit more complicated and require slightly deeper knowledge of the java annotation processing APIs. there is some documentation you can find on writing code generation plugins here: https://github.com/yahoo/squidb/wiki/Taking-control-of-code-generation. I also rewrote the entire code generator on our dev_4.0 branch some time ago with a much improved plugin API based on square's javapoet, so if you'd like to use the cutting edge you might have an easier time with creating your own codegen hooks, although it's not as well documented as the 3.0 version. either way, happy to offer more detailed assistance if that sounds like an approach you're open to!
Is there some way to safely deprecate database fields that are not used anymore? E.g. I have a field that's called "name" and then I upgrade my table to have a field called "firstname" and "secondname" and I deprecate the "name" field. I don't remove it from the table as there is no way to delete a column from sql without creating a new table and copying everything over, deleting the original table and renaming the copy. I want to keep the field in my specs file and want that the compiler throws a build exception if I ever again declare a field with the database name "name". Is something like this supported? Any security mechanism I can use to avoid creating new fields that may exist in some version of my app to avoid conflicts because of this?
@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 @Deprecatedand 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...
@MFlisar good points. of course,
@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
The name was just a quick idea, it's not good I know. I personally don't mind what the default behaviour is (although my personal opinion is safety first, so the build should fail by default if you ask me) as long as I get the possibility to do what I want. Thanks for considering this feature.
