@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.
exapmle-> CREATE PROCEDURE
BEGIN
select * from user
END
new_procedure ()BEGIN
select * from user
END
however, you can define methods in java to do whatever read/write operations you want
or, to parameterize things:
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)));
}
pretty much you just define java methods with whatever parameters you need, and convert that into queries or transactions that you can execute on an instance of
SquidDatabase
you can use subqueries or views to refer to other queries at the SQL level
or you can define java methods for common tasks at the application level
maybe if you give me a more concrete example of the task you're trying to accomplish I can help with other suggestions
Hello. I am using a shared "core" library that is shared between android and ios.
I wanted to include the squidb + annotations without the squidb-android in the core library and include it in the android project.
Unfortunately I get errors that go away if I add all the related squidb dependencies to the android project and remove everything from the core library.
Is there a way around it?
I wanted to include the squidb + annotations without the squidb-android in the core library and include it in the android project.
Unfortunately I get errors that go away if I add all the related squidb dependencies to the android project and remove everything from the core library.
Is there a way around it?
Hi @erasmospunk, what you describes sounds like the right concept of setup, so you might need to share more details of the specific error you're seeing. but generally yes, you should create a
core library that depends on squidb and squidb-annotations. then your android code depends on core and squidb-android, and your iOS code depends on core and squidb-ios.
without having any further details this is just a wild guess, but did you declare the dependencies in code using
api instead of implementation? I believe that only dependencies declared with api will become part of the public api of a shared module
/Users/xxxxxxxx/Downloads/squidb-master/squidb-ios/src/com/yahoo/android/sqlite/SQLiteDatatypeMismatchException.java:19: cannot find symbol
symbol: class SQLiteException
symbol: class SQLiteException
Please let me know
Currently still using squidb v3, but I have one suggestion: I like to split up my projects in modules for android and I always create a db module. I would like to hide all squidb code in there, but I have a problem. If I define public interfaces in my core module and want to expose setters, I always need to define setters with the return type of
TableModel. Would it be possible to disable this queuing supporting setters and instead only create setters with void return types? This way, I would not need to write extra setters to hide the complete squidb classes within one module nor to write extra setters with void return value...
No easy wa
No easy way without a plugin, but what about defining your interface to use a return type that’s your interface instead of TableModel? I would think that would work since the return type of the setters should be the actual class type
@abdulwd
No, queries and other db ops are synchronous. Threading choice is left up to the caller — you could use async tasks, thread pools, rx, whatever makes most sense for your app
Additionally, kotlin is not yet supported by yur processor, is it? E.g. static function are defined in a companion object in kotlin. If I define
ModelMethods there, those are not converted to class functions correctly... Can try this again, if you want to know the concrete problem (I think it was that those methods stayed static methods...)
I would have some suggestion for a very useful plugin: I think it makes sense to hide database code in a module (in android) or in some other private package e.g. so that the final implementation is hidden from the code that uses the database classes. Would it be possible to enable generating interfaces for each data model? This would be very handy for this use case...
@MFlisar as to your first question, that's correct, there's nothing in the processor (or any part of squidb, really) that does anything special for kotlin. as to your second question, sure, you could write a plugin that used the
declareAdditionalJava hook to generate an entirely new file based on the properties in the model spec. I'm not sure that I see too much value in this though -- an interface abstracts away implementation details so that multiple different implementations can be provided. in this case, there would be a 1-1 correspondence between the interface and its implementation, since a squidb model is really just a data transfer class. any alternative implementation wouldn't be accepted by the squidb database classes (since it expects AbstractModel etc.)
plus, the interface would be tightly coupled to the processor generating it, so it wouldn't be of much help in abstracting away data models for switching to other data layers either
or maybe you have some use case in mind I haven't thought of?
My main purpose of the interface abstraction is modularisation and compile time optimisation. Writing a database module, then generating the interface in a minimal core module und using the interface in the ui and some other modules has the big advantage, that non of my other modules have any dependency on any database code... E.g. I have a highly customisable app with hundreds of settings, I have a ui module, a settings module, a image loading module and all of them use the common data interfaces... Second good thing here is, that annotation processors are slowing down compile time as well, moving them to small modules that don't change often can improve compile time as well...
Secondly, is kotlin support planned? I use extension functions that only work in kotlin, so kotlin support would be nice for me...
@MFlisar I don't have nearly enough kotlin expertise to be able to do anything special in the annotation processor, but according to this doc, annotation processing should "just work" in most cases. which makes sense, it's really the responsibility of the compiler to present to the annotation processor a consistent view into the code being compiled. the annotation processor is very limited by what the compiler provides to it. you mentioned some kind of issue with static methods in companion objects; did you annotate them with
@JvmStatic as is documented there?
Hi @tomerpetel, good question. we had looked at introducing support for SQLCipher several years back, but at the time they were based on outdated/buggy versions of the android SQLite classes, so were deemed incompatible. it looks like in the years since they may have updated their code, so it is possible that it would work now, but I haven't tried it. if you wanted to give it a try, your goal would be to provide implementations of
ICursor, ISQLiteDatabase, ISQLitePreparedStatement, and ISQLiteOpenHelper that wrap the corresponding SQLCipher classes. This is usually a pretty direct wrapping; you can find examples of an implementations here, which are the wrappers for the android SQLite bindings project: https://github.com/yahoo/squidb/tree/master/squidb-addons/squidb-sqlite-bindings/src/com/yahoo/squidb/sqlitebindings. then you just override createOpenHelper in your database to return your SQLCipher implementation, similar to how its documented here: https://github.com/yahoo/squidb/wiki/Using-a-custom-SQLite-build
if you decide to try this, I highly recommend you clone and run the full squidb unit tests with your SQLCipher wrappers enabled, since our test cases should verify whether or not they've updated to newer source that fixes the problems we were seeing
your other option is to pay for a license for the official SQLite encryption extension, but I do not know if they support android or not: https://www.sqlite.org/see/doc/trunk/www/readme.wiki
basically, all security of the type you're talking about would happen below the squidb level, since squidb is just a layer on top of the existing SQLite android classes. so if any of these encryption solutions have low-level SQLite access classes based on the android SQLite classes from v14 or higher, then in theory it should be possible to write the adapters to plug them into squidb
Are you planning to support immutable models in the future? I currently always clone my models and adjust their attributes and push them back in a redux like store and if I forget to clone my model and adjust it directly this results in quite some problems, so it would be really nice to be able to create immutable models...