Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Jacob Martin
    @cube2222
    29212981_1756727781077028_7441421119703220224_n.gif
    Piotr Aleksander Styczyński
    @styczynski

    Hej :3 pomysł Octosqla jara mnie od samego początku xD a że lubię w przerawach coś kodzić dla przyjemność to z chęcią dodałbym jakieś funkcjonalności najlepiej takie które nie kolidują z głównym kierunkiem rozwoju żeby wam nie przeszkadzać a jednocześnie zrobić coś fajnego dookoła. :3
    Mam taką listę pomysłów:

    https://docs.google.com/document/d/1o-7BGoqyT7MNBN4QkYOyLMMFVmOJZ60OTuinc9yQxe0/edit

    Jak jest coś co fajnie byłoby mieć i coś co mógłbym zrobić to też jestem otwarty na propozycje. Najlepiej jakieś takie rzeczy które wam nie przeszkadzają i nie są najważniejszymi ficzerami żeby potem nie było problemu z wydzieleniem tego co było napisane w ramach licencjatu a co nie np ale żebym miał frajdę z napisania czegoś fajnego xD

    Jacob Martin
    @cube2222
    Maybe let's stick to english in the public gitter ;) Will make the project more approachable to others. I'm pumped that you're so eager to help! :D
    I think it's good to keep away from the parts we're doing for our bachelors for now, that's true.
    Anyways, I think the feature with datasources as table valued functions is a great idea. There's actually an issue weighing approaches to this: cube2222/octosql#135
    We are planning to split octosql into a client/server architecture in the future, so I think for a REPL it would be important to be easily adaptable to this split-up
    Ad using init for registration, you still have to import them, so it just ends up being a little bit less explicit in my opion (though I'm open to debate)
    ad "Optional validation for data source configuration?
    Validate data source using json schema or something else and return pretty results understandable by user i.e “Missing configuration property: sth” or “Property should be valid url” etc." I was actually thinking about using protobuf and proto-validate for this, like envoy does. https://github.com/envoyproxy/envoy
    The self-inspection stuff including SHOW will probably collide with the client-server split, so it should probably wait. But it would surely be a good idea, the underlying mechanisms could be great for adding REPL autocomplete.
    Jacob Martin
    @cube2222
    Other than that, I suppose currently one thing to add is inline JSON query support for objects. Though it's fairly simple in terms of code, the tricky thing is to figure out an ergonomic symtax for it. I'm not sure if the SQL standard syntax is great, or the Postgres (which partly conforms) one, this would require some research and probably an RFC before writing anything.
    @styczynski ^^^
    Jacob Martin
    @cube2222
    And btw. table valued functions are already here, the tumble and range functions namely. https://github.com/cube2222/octosql/wiki/Table-Valued-Functions-Documentation
    Jacob Martin
    @cube2222
    Oh, just wanted to add one core requirement in the topic of native-bindings and datasources, we don't want to have to use cgo to compile octosql.
    Piotr Aleksander Styczyński
    @styczynski

    @cube2222
    Yeah, I agree, I wouldn't like the presence of cgo-dependent code inside Octosql repository.

    I generally agree with everything you said.
    I didn't know that there's any builtin TVF like range etc. I will check how that works :3

    The REPL will require only some kind of interface so as you said it will conform the split-up.

    I will look at how envoy is utilizing proto-validate.

    From all the mentioned things I could look at cube2222/octosql#135 and try to work out the best approach and consult that with you.

    Jacob Martin
    @cube2222
    That would be amazing :)
    @styczynski
    Piotr Aleksander Styczyński
    @styczynski

    btw I think that the problem with stdin ambivalence could be resolved by introducing typed scalar functions for that. Let me know what you think about that @cube2222 :3
    There could be a stdin() function that returns a scalar value - stream object and a TVF that accepts it so reading a csv from stdin would look like this:

      SELECT * FROM loadfile(type => 'csv',  input => stdin())

    We can potentially add multiple possible inputs so that the code is more composable.
    We can introduce a little (very primitive) type system to perform type checking.

    Jacob Martin
    @cube2222

    We already thought about a restructure where we could make datasources more composable. Instead of having a json data source provide a file datasource with a pluggable decoder (json, csv, etc). Would then be easy to add something like S3 blobs with various decoding. That would be a big one tho.

    Anyways, I'm a little bit afraid of adding stuff like stream objects in SQL. So maybe we'd just add an argument stdin => true? That would be the most simple in the current state of things.