Yes. Actually adding a GlassfishDialect subclass might make things simpler too
On 28 sept. 2010, at 19:29, Sanne Grinovero wrote:
> 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
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 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 th
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
> appli
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
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)")
- Origina
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.
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 binding
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
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 glassfish
"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
Thanks to both of you.
Norm
On Tue, Sep 28, 2010 at 5:21 AM, Emmanuel Bernard wrote:
> 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
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
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
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
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
21 matches
Mail list logo
