On Monday, 4 September 2017 at 15:11:37 UTC, Boris-Barboris wrote:
> On Monday, 4 September 2017 at 14:42:31 UTC, denizzzka wrote:
>> https://github.com/denizzzka/vibe.d.db.postgresql uses dpq2 backend
>
> https://github.com/denizzzka/vibe.d.db.postgresql/blob/master/source/vibe/db/postgresql/package.d#L92
>
> Very interesting read, thank you.

?

> Making this:
> https://github.com/denizzzka/vibe.d.db.postgresql/blob/master/source/vibe/db/postgresql/package.d#L131
> private is probably a crime against humanity though.

What do you mean?

> I mostly bothered with EQ protocol because I wanted to send PARSE + BIND + EXEC + SYNC without blocking. Is that possible with socket blocking flag manipulation and moderate source code modification?

Possible without any src modify.

On Monday, 4 September 2017 at 15:28:11 UTC, denizzzka wrote:
> What do you mean?
It seems like a very generic method way to send batched messages, wich would give a lot of freedom.

> Possible without any src modify.

Will linux socket get a send called between them, or it will be buffered by libpq\dpq2?

On Monday, 4 September 2017 at 15:32:51 UTC, Boris-Barboris wrote:
> On Monday, 4 September 2017 at 15:28:11 UTC, denizzzka wrote:
>> What do you mean?
> It seems like a very generic method way to send batched messages, wich would give a lot of freedom.

This is just internal function. Don't try to call it from your application.

>
>> Possible without any src modify.
>
> Will linux socket get a send called between them, or it will be buffered by libpq\dpq2?

Oh... What is it:
PARSE + BIND + EXEC + SYNC
?

On Sunday, 3 September 2017 at 22:57:39 UTC, Boris-Barboris wrote:

> If anyone here has some insight on typical architectural errors wich make ORM writer's life hard, please share.

Also, ORM is typical architecturial error.

https://en.m.wikipedia.org/wiki/Object-relational_impedance_mismatch

On Monday, 4 September 2017 at 15:40:47 UTC, denizzzka wrote:
> This is just internal function. Don't try to call it from your application.

I guess it's the Python curse

> Oh... What is it:
> PARSE + BIND + EXEC + SYNC
> ?
Yeah, that's what I do currently, just write the whole command chain (same goes for transaction control statement, they take 15-20 bytes before\after actual commands, so no need to send them separately) when it's built, flush it to socket and block until all results come back, finalized by ReadyForQuery message.

On Monday, 4 September 2017 at 15:45:23 UTC, denizzzka wrote:
>
> Also, ORM is typical architecturial error.
>
> https://en.m.wikipedia.org/wiki/Object-relational_impedance_mismatch

It's a tool. Error is when you use wrong tool for your job. ORMs surely help many people, and do a lot of good.

On Monday, 4 September 2017 at 15:47:04 UTC, Boris-Barboris wrote:
> On Monday, 4 September 2017 at 15:40:47 UTC, denizzzka wrote:
>> This is just internal function. Don't try to call it from your application.
>
> I guess it's the Python curse
>
>> Oh... What is it:
>> PARSE + BIND + EXEC + SYNC
>> ?
> Yeah, that's what I do currently, just write the whole command chain (same goes for transaction control statement, they take 15-20 bytes before\after actual commands, so no need to send them separately) when it's built, flush it to socket and block until all results come back, finalized by ReadyForQuery message.

I dare say that you are engaged in premature optimization.

On Monday, 4 September 2017 at 15:53:30 UTC, denizzzka wrote:
> I dare say that you are engaged in premature optimization.

Quite possible, but it took tolerable amount of time. I definetly will play with dpq2 more some day, maybe there is indeed no need to reinvent libpq. But what's done is done.

On Monday, 4 September 2017 at 15:47:04 UTC, Boris-Barboris wrote:
> On Monday, 4 September 2017 at 15:40:47 UTC, denizzzka wrote:
>> This is just internal function. Don't try to call it from your application.
>
> I guess it's the Python curse
>
>> Oh... What is it:
>> PARSE + BIND + EXEC + SYNC
>> ?
> Yeah, that's what I do currently, just write the whole command chain (same goes for transaction control statement, they take 15-20 bytes before\after actual commands, so no need to send them separately) when it's built, flush it to socket and block until all results come back, finalized by ReadyForQuery message.

Premature optimization, IMHO

non-blocking queries available in libpq, dpq2 and in vibe.d postgres supporting package too.

On Monday, 4 September 2017 at 15:59:47 UTC, denizzzka wrote:

Sorry fot duplicate answer