On Fri, 8 Oct 2021 at 15:44, mi...@ubo.ro wrote:
> I'm using the library with a nosql. I provided the sql example b/c it's
> part of the std library.
> I like rog's solution(especially on the generic Resource type) but to
> reduce friction and make it more idiomatic I would need to be able to
>
I'm using the library with a nosql. I provided the sql example b/c it's
part of the std library.
I like rog's solution(especially on the generic Resource type) but to
reduce friction and make it more idiomatic I would need to be able to
define the select arguments in the return func (after the
I think you can only do that if you make sql parsing a first class language
feature - or you need to construct the query using a syntax tree of clauses
which is a PITA. Sometimes a hybrid approach - not a full orm - but an sql
helper works best so
sql.Query(table name, field list, where
FWIW, I like the idea of being able to write direct SQL and still have some
static type checking. ORMs are OK for simple "get" and "put", but I have
been bitten so many times where I *know* the exact SQL I want for a
particular query, but the ORM makes it so damned hard to construct it their
On Wed, 6 Oct 2021 at 12:44, Robert Engels wrote:
> Personally, I think this is overkill (the entire concept not the rog
> solution)
>
I tend to agree, but the bait was too irresistible :)
I do think that using reflection in combination with generics the way I
showed can be really useful. This
Personally, I think this is overkill (the entire concept not the rog solution)
Even with static checking there is no way to ensure that tablex has the needed
fields. Even if you could check this at compile time - it might be different at
runtime.
I don’t think the juice is worth the squeeze.
On Wed, 6 Oct 2021 at 09:21, mi...@ubo.ro wrote:
> Hi Ian ,
>
> I've modified the example towards a more specific use case. The main idea
> in the example below is to make code related to database operations(i.e
> SELECT queries) safer and easier to read. A kind of
> json.Unmarshal/Marshal
Hi Ian ,
I've modified the example towards a more specific use case. The main idea
in the example below is to make code related to database operations(i.e
SELECT queries) safer and easier to read. A kind of
json.Unmarshal/Marshal for databases, with validation (type checking, param
numbers
On Sun, Oct 3, 2021 at 8:41 AM mi...@ubo.ro wrote:
>
> I have developed a library that depends very much on reflect package. It
> caches a specific type and return a function that encodes(does something
> with) with that kind /type of data. Think of defining database schema using
> types and
I don't think so. There is no way to decompose structs as part of
constraints, so you can't generalize over them easily. There is also no way
to generalize over an arbitrary number of types, which would be necessary
to write a signature of `ReturnFunc`.
On Sun, Oct 3, 2021 at 5:41 PM mi...@ubo.ro
I have developed a library that depends very much on reflect package. It
caches a specific type and return a function that encodes(does something
with) with that kind /type of data. Think of defining database schema using
types and generating functions to validate/update/insert data.
I reduced
11 matches
Mail list logo
