On 28 sept. 2010, at 17:53, Emmanuel Bernard wrote:
>
> On 28 sept. 2010, at 16:21, Steve Ebersole wrote:
>>
>>
>> 1) whether to combine read/write into one annotation : +1 from me, *so
>> long as* neither is required. And as we discussed, ideally the column
>> name would be optional too for
t;)
>
>
>
>
> - Original Message
> From: Paul Benedict
> To: Steve Ebersole ; Hibernate Developers List
>
> Sent: Tue, September 28, 2010 10:37:37 AM
> Subject: Re: [hibernate-dev] Annotation name for column-level read/write
> expression
>
> I am n
On 28 sept. 2010, at 16:21, Steve Ebersole wrote:
>
>
> 1) whether to combine read/write into one annotation : +1 from me, *so
> long as* neither is required. And as we discussed, ideally the column
> name would be optional too for single-column values.
I've made the change. We are left with t
edit_card_num, key)")
- Original Message
From: Paul Benedict
To: Steve Ebersole ; Hibernate Developers List
Sent: Tue, September 28, 2010 10:37:37 AM
Subject: Re: [hibernate-dev] Annotation name for column-level read/write
expression
I am not in favor of @ColumnReadWrite in case someone design
On Tue, 2010-09-28 at 09:37 -0500, Paul Benedict wrote:
> I am not in favor of @ColumnReadWrite in case someone designs an
> enhancement that's tertiary: read, insert update. Okay, far-fetched,
> but still I don't want to limit any designs.
Not gonna happen.
--
Steve Ebersole
http://hibernate.
I am not in favor of @ColumnReadWrite in case someone designs an
enhancement that's tertiary: read, insert update. Okay, far-fetched,
but still I don't want to limit any designs.
@ColumnAccess is too close to JPA's access types of method/field.
I think we are really dealing with transformations h
Really we now have 2 discussions:
1) whether to combine read/write into one annotation : +1 from me, *so
long as* neither is required. And as we discussed, ideally the column
name would be optional too for single-column values.
2) What we want to name it. Personally I like "column" in the name
TransformOnRead TransformOnWrite ?
MutateOnRead/Write ?
/max
On Sep 28, 2010, at 15:28, Steve Ebersole wrote:
> "access" does not capture the essence of what you are doing though which
> is mutating values to and fro.
>
> On Tue, 2010-09-28 at 08:57 -0400, Chris Bredesen wrote:
>> read + write
"access" does not capture the essence of what you are doing though which
is mutating values to and fro.
On Tue, 2010-09-28 at 08:57 -0400, Chris Bredesen wrote:
> read + write = access
>
> @ColumnAccessExpression?
>
> On 09/28/2010 07:33 AM, Steve Ebersole wrote:
> > Really we went through the s
read + write = access
@ColumnAccessExpression?
On 09/28/2010 07:33 AM, Steve Ebersole wrote:
> Really we went through the same discussion when developing the original
> feature in terms of what to "call it" when discussing/documenting it. I
> like the "read" and "write" aspects; its the general
What about a simple uppper/lower write?
On Tue, 2010-09-28 at 09:58 +0200, Emmanuel Bernard wrote:
> I've tried @ReadExpression / @WriteExpression but I was not happy about it
> because of the forColumn duplication. That made the construct a lot more
> verbose.
> And all the examples I've found
Really we went through the same discussion when developing the original
feature in terms of what to "call it" when discussing/documenting it. I
like the "read" and "write" aspects; its the general quality of applying
read/write thats tougher to term.
Another option is @ColumnReadWrite.
On Tue
As of right now, yes.
Trying to support it was not super trivial but I can give it a second round
today.
@ReadWriteWrapper would work. We don't use wrapper though in the doc for this
feature but that can be changed.
On 28 sept. 2010, at 05:54, Steve Ebersole wrote:
> Is the 'forColumn' attrib
I've tried @ReadExpression / @WriteExpression but I was not happy about it
because of the forColumn duplication. That made the construct a lot more
verbose.
And all the examples I've found need both.
On 28 sept. 2010, at 00:16, Paul Benedict wrote:
> I am not happy about @ReadWriteExpression ei
Is the 'forColumn' attribute required if a single column value?
On Mon, 2010-09-27 at 22:53 -0500, Steve Ebersole wrote:
> @Wrapper(
> forColumn="credit_card_num",
> read="decrypt(credit_card_num)",
> write="encrypt(?)"
> )
>
> @ReadWrapper( forColumn="credit_card_num",
> express
@Wrapper(
forColumn="credit_card_num",
read="decrypt(credit_card_num)",
write="encrypt(?)"
)
@ReadWrapper( forColumn="credit_card_num",
expression="decrypt(credit_card_num)" )
@WriteWrapper( forColumn="credit_card_num", expression="encrypt(?)" )
On Tue, 2010-09-28 at 00:10 +0200
I am not happy about @ReadWriteExpression either. Why not just
@ReadExpression and @WriteExpression? I don't even think you need the
forColumn attribute -- it could be derived out of the metadata.
On Mon, Sep 27, 2010 at 5:10 PM, Emmanuel Bernard
wrote:
> Hey guys,
> I've implemented
> http://op
17 matches
Mail list logo
