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
Getting the underlying tx state is more useful to me.
On 28 sept. 2010, at 05:49, Steve Ebersole wrote:
Currently there is a big discrepancy between the documentation for some
of the methods on org.hibernate.Transaction and the actual code.
Specifically the methods isActive(), wasRolledBack()
Simply look at the Dialect source code of the database that is closest to
yours, or use the generic Dialect code and start from there. That's the best
approach.
On 27 sept. 2010, at 14:55, Norman Bauer wrote:
Could anyone provide me with links to any guidance docouments/articles on
creating
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'
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,
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
Thanks to both of you.
Norm
On Tue, Sep 28, 2010 at 5:21 AM, Emmanuel Bernard emman...@hibernate.orgwrote:
Simply look at the Dialect source code of the database that is closest to
yours, or use the generic Dialect code and start from there. That's the best
approach.
On 27 sept. 2010, at
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 quality
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 same
Hi Emmanuel,
do you have any clue about this issue in the forum thread mentiond below?
I thougth they might be missing the transactionmanager registration, but a)
I'd expect a different exception b)there's no mention of Glassfish in the
Hibernate core documentation.
Is it possible that in
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 =
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
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
It really really really looks like they don't set up the transaction manager in
their config (for sure the code sample in the forum does not have the property).
They should use SunONETransactionManagerLookup (previous name for GF.
Alternatively, it could be like:
- GF v3 has changed it's
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 st...@hibernate.org
There is a perfectly reasonable use case for a binary operation (though it
still
applies to one column).
From your credit card example, there is sometimes more than one key.
@ReadWriteExpression(
read=decrypt(credit_card_num, key),
write=decrypt(credit_card_num, key))
- Original
Which you are perfectly free to do:
@Whatever(
column=credit_card_num,
read=decrypt(credit_card_num, '123),
write=encrypt(?, '123')
)
On Tue, 2010-09-28 at 08:12 -0700, Justin Sands wrote:
There is a perfectly reasonable use case for a binary operation (though it
still
applies to
In that case what would you like to see happen when say
Transaction.isActive() is called but the UserTransaction or
TransactionManager cannot be found? Or when they report that the status
is UNKOWN? Currently we throw exceptions in both of those cases which
is do not think is uber-useful.
In
thanks Emmanuel,
yes the SunONETransactionManagerLookup is the same I had recommended
earlier in the same discussion, but had to look it up in source code
to find out and wasn't 100% sure;
I've repeated that now in the forums, this is the fourth user I meet
having issues with it.
Shall I add it
Yes. Actually adding a GlassfishDialect subclass might make things simpler too
On 28 sept. 2010, at 19:29, Sanne Grinovero sanne.grinov...@gmail.com wrote:
thanks Emmanuel,
yes the SunONETransactionManagerLookup is the same I had recommended
earlier in the same discussion, but had to look it
20 matches
Mail list logo
