[DBIx-Class-Devel] people/abraxxa/doc_plain_value_removal

[Peter Rabbitson]

On Wed, Apr 03, 2013 at 03:32:15PM +0200, Alexander Hartmaier wrote:
> On Wed, Apr 3, 2013 at 2:37 PM, Peter Rabbitson <rabbit+dbic at rabbit.us>wrote:
> 
> > On Tue, Apr 02, 2013 at 05:00:06PM +0200, Alexander Hartmaier wrote:
> > > I've started working on my first todo item [1] to remove the plain_value
> > > bind value workaround from the docs, please review the changes I've split
> > > up into three commits in people/abraxxa/doc_plain_value_removal.
> > >
> >
> > Please review and adjust your work in 8a5c4a2a according to the new
> > feature that landed in topic/constructor_rewrite (d7ef033).
> >
> The new syntax is nice and concise.
> Do we want to separate the 'backward compatible' and 'convenience'
> shortcuts?

I am not sure which one you mean "backwards compatible". They all have their
place.

> I'd like to add a suggestion for the user which of the available syntaxes
> he should use (and why).

Please do so. The original explanation and how things work is contained 
in the commit message of 0e773352 [1]. SineSwiper since adapted it into 
a doc in 00c12490b [2][3]. If you hve any further questions (i.e. 
something unclear) - do ask.

> I assume specifying the sqlt_datatype if no dbic colname can be used is the
> preferred way.

Yes, though really specifying *nothing* unless it is necessary is what I 
would call "the preferred" way. Specifyin a bogus column however is a 
bug yes.


> If yes I'd restructure to list the available options after their preference
> ranking.

There is no preference as such - you need plain values 99% of the time, 
but the other 1% you *can't* get away without specifying something. It 
all boils down to the DBD bind attributes, for example crap like [4].

> 
> Should I really base my doc work on unreleased work in
> topic/constructor_rewrite?

Yes in this (rather exceptional) case because:
1) stuff will be merged to master within a week
2) the simplified syntax is not available in master (and is hard to backport
for no obvious benefit)

> If so I'd rebase it against topic/constructor_rewrite to make clear that it
> needs topic/constructor_rewrite merged to master before it can be merged
> too.

Correct. Though note that constructor_rewrite itself will be rebased at
least 2 more times, so your "parent" will get away (not critical, just
annoying)

> Another solution to also do the doc work in the topic/constructor_rewrite
> branch.

That would be silly double work.