Fixed
Status Update
Comments
sp...@gmail.com <sp...@gmail.com> #2
Hey,
same api error/question here.
We would like to try out experimental feature as well.
same api error/question here.
We would like to try out experimental feature as well.
sp...@gmail.com <sp...@gmail.com> #3
We need it too... Did anyone find how we can get it ? Blocked with "Field based partitioning support is not yet available for this project" API error...
uc...@google.com <uc...@google.com>
al...@google.com <al...@google.com>
ch...@google.com <ch...@google.com> #4
We are waiting on a few approvals to start alpha for this feature shortly.
Please watch this bug for more updates.
Please watch this bug for more updates.
[Deleted User] <[Deleted User]> #5
That is great to hear!
I have one important question though regarding this new feature. Is it going to be implemented in such a way that we have the option to:
1) Select any column / field for partitioning BUT ALSO KEEP the time based partitioning on top of that?
2) OR is it going to be implemented in such a way that we can choose to partition on ONE FIELD ONLY, either being time or something else?
We need scenario 1 :)!
I have one important question though regarding this new feature. Is it going to be implemented in such a way that we have the option to:
1) Select any column / field for partitioning BUT ALSO KEEP the time based partitioning on top of that?
2) OR is it going to be implemented in such a way that we can choose to partition on ONE FIELD ONLY, either being time or something else?
We need scenario 1 :)!
ch...@google.com <ch...@google.com> #6
Currently looking into doing 90000 different tables. Getting Scenario 1 as described above would allow us to just use 1.
ch...@google.com <ch...@google.com> #7
We are currently doing a controlled alpha release for date/timestamp column based partitioning. Development is actively underway on scenario (1) that you outlined above. I don't have a good ETA to provide at this point, unfortunately.
Description
Build #AI-171.4443003, built on November 9, 2017
Mac OS X 10.13.3
Version of Gradle Plugin: 3.0.1
Version of Gradle: 4.5
Version of Java:
JRE: 1.8.0_152-release-915-b08 x86_64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
OS: Mac OSX High Sierra
Steps to Reproduce:
It seems that altering the projectDir in the settings.gradle causes issues with Android Studio. This works perfectly in IntelliJ.
Other people are encountering this, commenting inside
1. Here is my settings.gradle
```
include ':android:app',
':shared',
':react',
':react-native',
':javascript',
':task-common',
':task-js'
def libsPath = "$rootDir/libs"
def jsDefinitionPath = "$libsPath/definitions"
project(':javascript').projectDir = "$jsDefinitionPath/javascript" as File
project(':react').projectDir = "$jsDefinitionPath/react" as File
project(':react-native').projectDir = "$jsDefinitionPath/react-native" as File
project(':task-common').projectDir = "$libsPath/task/common" as File
project(':task-js').projectDir = "$libsPath/task/js" as File'
rootProject.children.each {
it.buildFileName =
}
```
2. Then in my `:shared` I'm importing other projects as dependencies.
```
compile project(':javascript')
compile project(':react-native')
```
When I try to sync, I get errors in Android Studio. The issue is either caused by changing the `projectDir`, or by altering the build file name. Again, this works just fine IntelliJ or when using gradle via command line.