Replies: 18 comments 6 replies
-
|
To be honest I don't understand exactly your comment. First of all there is no kotlin native driver (written in pure kotlin) outhere, the ecosystem is in a very young stage. Secondly this project does not target jvm at all, so the comparison with jdbc is not accurate. Although this project (also sqlx) they were build with jooq in mind but of course I didn't copy it. Also, I understand that maybe I could come up with a more kotlinish api. That's probably true, in that case I would be happy to also view your opinion on that. After all it's a two month project written exclusively by me. I think it's not a fair comparison with projects that have several contributors. Thanks a lot 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
Also, I enabled the discussions. So, I'll close this (since it's not an actual issue). And feel free to open a thread in the discussions. |
Beta Was this translation helpful? Give feedback.
-
|
Do you mind converting this "issue" to a discussion, so we can better talk there ? |
Beta Was this translation helpful? Give feedback.
-
|
@teras I just migrated it to a discussion. |
Beta Was this translation helpful? Give feedback.
-
Of course it is. There's a niche here, and discussing how to fill this gap is what makes open source flourish.
It doesn't indeed, but, even if we don't like it, the most people have a Java background. Moreover having a proven API makes the library more easy to understand and use. Again, it's only about the API, and only where it's required. Even if this is only 1% of the "parent" project.
As you said, Kotlin is still a fresh fruit. That's why I prefer a javaish API, "compatible" with the old school. And again the reason of it is, help people jump on the ship and easily migrate to this project instead.
I don't compare. on the contrary I find this as an "excuse" and a good opportunity to think big with fellow programmers and create the next "successful" (remember: think big) project. Let me explain why I am talking about this, this way. As I said I am creating a lightweight JPA-like library, that throws away all the JPA bloatware and keep the good stuff. Still, it needs low level database connectivity, in Kotlin Native. In Kotlin/JVM we already have JDBC for that, and works really well. While I was waiting for this to happen, or validating my free time to start a project like this, your message appears and for me, again, is an opportunity to join forces and create something that even more people will use and be happy with this. My target right now is desktop machines that can connect with a database, not iOS or Android devices. At least for now. I believe I made myself more clear and I'd be happy to continue this discussion if you want too. |
Beta Was this translation helpful? Give feedback.
-
|
Sure, I would like to continue this discussion. I totally agree with your point about joining forces. If you want, we could start talking on the API that you are building. So, feel free to share your ideas. Also if you have a public repository of the API project that you are making please share a link. PS: the next days I'll be on vacations until Sunday. |
Beta Was this translation helpful? Give feedback.
-
|
Author The code is not officially released yet, although it's in a working environment for a couple of months and proved itself solid. For the sake of the argument I uploaded the code for you to have a look. Right now it's java only, for obvious reasons; changing to kotlin is dead simple. It is used solely in a couple of kotlin projects anyway. There are some kotlin extensions that aren't pushed yet. The API is the standard JDBC API and is using only a few methods, like prepared statements, connection/connection pool , and some properties, like transactions etc. All and all are not a lot. Since it supports most major DBs (MySQL/MariaDB, Postgresql, Oracle, SQL server and sqlite), it also requires to identify which DB is underneath using connection properties. My plan is. if there is some interest, to convert this to kotlin, since, as you said, it's still new ground and it's easy to make it useful to others, compared to the saturated java ecosystem. The API would remain Java-like though, but totally kotlin friendly. I just uploaded most of the code. Needs a lot of refinement, and documentation of course. It has all the create/update/delete/query methods that any decent ORM would request. |
Beta Was this translation helpful? Give feedback.
-
|
Given your question about the API. I am in the process of migrating Java code to Kotlin native (and yes, it's really challenging). I give you the list (up to now) to have a reference what's required. Note that all are extension functions, in order not to collide with the actual API and inheritance. Note: I don't ask to have the same name, I only seek for similar functionality. Note 2: The names of the methods are kept close to the original names as possible. Only one var wasn't (and transformed to function) because the compiler didn't let me do it. internal expect val DataSource._connection: Connection
internal expect val Connection._metaData: DatabaseMetaData
internal expect fun Connection._prepareStatement(sql: String, generatedKeys: Boolean): PreparedStatement
internal expect fun Connection._disableAutoCommit()
internal expect fun Connection._enableAutoCommit()
internal expect fun Connection._setSavepoint(sp: String): Savepoint
internal expect fun Connection._releaseSavepoint(savepoint: Savepoint)
internal expect fun Connection._rollback(savepoint: Savepoint? = null)
internal expect fun Connection._commit()
internal expect fun Connection._prepareCall(s: String): CallableStatement
internal expect val DatabaseMetaData._databaseProductName: String
internal expect val DatabaseMetaData._databaseProductVersion: String
internal expect val DatabaseMetaData._databaseMajorVersion: Int
internal expect val DatabaseMetaData._databaseMinorVersion: Int
internal expect fun PreparedStatement._executeUpdate(): Int
internal expect fun PreparedStatement._executeQuery(): ResultSet
internal expect fun PreparedStatement._setObject(i: Int, any: Any?)
internal expect fun ResultSet._next(): Boolean
internal expect val ResultSet._columnCount: Int
internal expect fun ResultSet._getColumnName(index: Int): String
internal expect fun ResultSet._getObject(index: Int): Any?
internal expect fun CallableStatement._getObject(idx: Int): Any?
internal expect fun CallableStatement._registerOutParameter(i: Int, convertNativeTypeToSQLType: Int)
internal expect fun CallableStatement._execute()just for reference, to have an idea, are the list of JVM interfaces that database connectivity is based upon. actual typealias Statement = java.sql.Statement
actual typealias PreparedStatement = java.sql.PreparedStatement
actual typealias DataSource = javax.sql.DataSource
actual typealias Connection = java.sql.Connection
actual typealias DatabaseMetaData = java.sql.DatabaseMetaData
actual typealias Savepoint = java.sql.Savepoint
actual typealias ResultSet = java.sql.ResultSet
actual typealias CallableStatement = java.sql.CallableStatementAgain, as a reference, the actual JVM alias. Again the API and implementation details can be completely different: internal actual val DataSource._connection get() = connection
internal actual val Connection._metaData get() = metaData
internal actual val DatabaseMetaData._databaseProductName get() = databaseProductName
internal actual val DatabaseMetaData._databaseProductVersion get() = databaseProductVersion
internal actual val DatabaseMetaData._databaseMajorVersion get() = databaseMajorVersion
internal actual val DatabaseMetaData._databaseMinorVersion get() = databaseMinorVersion
internal actual fun Connection._disableAutoCommit() {
autoCommit = false
}
internal actual fun Connection._enableAutoCommit() {
autoCommit = true
}
internal actual fun Connection._rollback(savepoint: Savepoint?) =
if (savepoint != null) rollback(savepoint) else rollback()
internal actual fun Connection._setSavepoint(sp: String): Savepoint = setSavepoint(sp)
internal actual fun Connection._releaseSavepoint(savepoint: Savepoint) = releaseSavepoint(savepoint)
internal actual fun Connection._commit() = commit()
internal actual fun Connection._prepareStatement(sql: String, generatedKeys: Boolean) =
(if (generatedKeys) prepareStatement(
sql,
PreparedStatement.RETURN_GENERATED_KEYS
) else prepareStatement(sql)) as PreparedStatement
internal actual fun PreparedStatement._executeUpdate() = executeUpdate()
internal actual fun PreparedStatement._executeQuery(): ResultSet = executeQuery()
internal actual fun ResultSet._next() = next()
internal actual val ResultSet._columnCount get() = metaData.columnCount
internal actual fun ResultSet._getColumnName(index: Int) = metaData.getColumnName(index)
internal actual fun ResultSet._getObject(index: Int) = getObject(index)
internal actual fun PreparedStatement._setObject(i: Int, any: Any?) = setObject(i, any) |
Beta Was this translation helpful? Give feedback.
-
|
Hello! I think probably in the next few days I'll merge the branch. |
Beta Was this translation helpful? Give feedback.
-
|
Of course I understand the procedure. That's the reason I send you as early as possible my "needs" to understand what we're talking about. Btw. Statement itself isn't really useful. It's only when you want to use unchecked queries and put speed over safety. |
Beta Was this translation helpful? Give feedback.
-
|
In reality will be the same, will work as a PreparedStatement (as |
Beta Was this translation helpful? Give feedback.
-
|
I just published the new API. If you want take a look: I'm planning to do several other changes. |
Beta Was this translation helpful? Give feedback.
-
|
@teras |
Beta Was this translation helpful? Give feedback.
-
|
Nice. So after a really hard refactoring and bumping into the wall a couple of times due to native missing features, this is the first version of the library here, as native. https://github.com/teras/stormify/tree/native It is still missing the compiler plugin, since native doesn't support reflection and thus, all information should be gathered at run time. My goal is not to disable reflection at all, since JVM libraries might depend on this, but to make it optional. I am going to have a second look at your API with the compiler plugin is ready and at least the JVM version is totally working with no issues. In the mean time, the actual native stuff that the library needs, as low level drivers, is here: Types; https://github.com/teras/stormify/blob/native/db/src/commonMain/kotlin/onl/ycode/stormify/DatabaseTypes.kt |
Beta Was this translation helpful? Give feedback.
-
|
Nice. @teras are you planning to make use of coroutines? Also, how are you going to generate the queries for the native code (since there is no reflection)? Are you going to create a compiler plugin? How you going to generate the code? KotlinPoet? |
Beta Was this translation helpful? Give feedback.
-
|
As a core feature, I think not. I believe in distinction between what a library should do and what it shouldn't. Being parallel is part of a library that connects to the database or is it something that the user should specifically initiate? Since there's no reflection there's only one way to do it, the compiler plugin as I mentioned. It also needs to gather entity information from dependency libraries, and all those to work together with native, so it's not that easy. And on top of that to be KSP2 to be future proof. Which might be a benefit, since it can only be a preprocessor, not a strict compiler plugin. I'll see how it goes. The queries again shouldn't be part of the library itself. After 25 years of experience I can safely say that there's no (complex) case that uses a database and doesn't need to write a custom SQL-level query. So why bother with high end libraries that never do what you want and you have to learn two syntax? Why not only learn the most expressive, safe, and universal way, the SQL syntax itself? If the user wants to use a high(er) level library to create the actual queries, he can do it. But that's not part of the scope of this library. Now about KotlinPoet, no I don't need that. To create fixed source code it's much much much easier to make it yourself. Not to mention faster, easier, having more control and not depending on external libraries that can break at any time. I have quite some experience with compiler plugins and generated code, so there's no issue with this point. |
Beta Was this translation helpful? Give feedback.
-
|
Then why you are building an orm? In the next releases I'm planning to add support for insert and update (auto generate code that will facilitate those operations). |
Beta Was this translation helpful? Give feedback.
-
|
ORM i(Object Relational Mapping.) supposed to map tabular (relational) data to objects. And all those using CRUD operations. Including references, lists and similar things. All other actions are not ORM IMHO; they are bloated features that make something complex, not user friendly and idiomatic. [ Although sometimes creating high level database (SQL) commands might fall in the ORM category, I already explained why I personally don't think is useful]. Adding create & insert is really useful, but actually part of the |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking about this: What about iOS/mac support? |
Beta Was this translation helpful? Give feedback.
-
|
Are fully supported. Check the supported targets in the readme file. |
Beta Was this translation helpful? Give feedback.
-
|
@teras Are you still working on your project? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, but I am giving priority to finalize the API with the JDBC first, and then the native part. |
Beta Was this translation helpful? Give feedback.
-
|
@teras are you still interested about this thread? |
Beta Was this translation helpful? Give feedback.
-
|
Indeed I am but work, holidays and life made me step backwards :( |
Beta Was this translation helpful? Give feedback.
-
This is more of a discussion board for this library, since no discussion is enabled. Please feel free to move this.
I understand that this is your project, but let me have a few comments about it. I had an overview and what was my first impression was the API. I am worried that there is one more API, given there's already a similar low level API: JDBC.
I mean, of course we don't want/need 100% implementation. Maybe only 10% is enough. But, this 10% to be virtually the same. Like for example, how transactions are implemented. The API should be Kotlin/Java/JDBC like and not Rust like. That's what I believe.
Beta Was this translation helpful? Give feedback.
All reactions