Seems we have same questions in second feature I wanted to implement -
qualifiers for DbEntities. Should they work for EJBQLs too? As far as I can
tell after looking at the code, current EJBQL doesn't use ObjEntity
qualifiers.
I can't think of anything better than implementing DbEntity qualifier as
On Jun 3, 2009, at 4:12 PM, Andrey Razumovsky wrote:
Let's first decide which approach above we'll be using (1.
intercept on
commit or 2. intercept of anything "delete").
I see. What implemented now is "1.5 - intercept of anything
DeleteBatchQuery". This might be okay if we plan #2 someda
>
>
>
> Let's first decide which approach above we'll be using (1. intercept on
> commit or 2. intercept of anything "delete").
>
I see. What implemented now is "1.5 - intercept of anything
DeleteBatchQuery". This might be okay if we plan #2 someday. Actually I want
this feature right now, and ch
On Jun 3, 2009, at 3:00 PM, Andrey Razumovsky wrote:
First, the main goal of the feature is to provide extension point for
insert/update/delete queries of context commit process.
This is what I thought initially. But you mentioning intercepting
delete queries at the lower levels made me thi
I'm a bit confused here. Let's try to make it clear.
First, the main goal of the feature is to provide extension point for
insert/update/delete queries of context commit process. Currently
*BatchQueries are responsible for those actions. But they can be used
separately. Should we keep original bat
Sorry for jumping the gun. Let me take it back for a moment. I was
still trying to understand how do we present this feature to a user,
and where it fits in the overall design. Now after this discussion, I
am clear on the intention (I think), and more comfortable with the
suggested concept
On Jun 3, 2009, at 12:01 PM, Andrey Razumovsky wrote:
I've never used that myself, but e.g. DeleteBatchQuery can be fired
separately using context.performAction(..). It is public in .query
package
after all. I don't want to have different behaviors for that
I disagree. I think we do want d
I've never used that myself, but e.g. DeleteBatchQuery can be fired
separately using context.performAction(..). It is public in .query package
after all. I don't want to have different behaviors for that
2009/6/3 Andrus Adamchik
> Let me rephrase. What other cases do we want to handle with this
Let me rephrase. What other cases do we want to handle with this
strategy, in addition to "commit" (that triggers flush action)?
Andrus
On Jun 3, 2009, at 11:51 AM, Andrus Adamchik wrote:
On Jun 3, 2009, at 11:45 AM, Andrey Razumovsky wrote:
Yes, but that will make factory working only in f
On Jun 3, 2009, at 11:45 AM, Andrey Razumovsky wrote:
Yes, but that will make factory working only in flush action, but
not if it
is fired from somewhere else.
Correct. But why do we want to do it differently?
Andrus
Yes, but that will make factory working only in flush action, but not if it
is fired from somewhere else. I've uploaded what I have now. Passing of node
is a quite blurry, but I can stand this solution
2009/6/3 Andrus Adamchik
>
> On Jun 3, 2009, at 11:24 AM, Andrus Adamchik wrote:
>
> You'd g
On Jun 3, 2009, at 11:24 AM, Andrus Adamchik wrote:
You'd generate a BatchUpdateAction instead of delete or something
like that.
I mean a BatchUpdateQuery not Action.
After all, batch queries are public and can
be fired from anywhere, including context.performQuery(..).
Exactly, BatchQuery is just that - a query. And we probably do not
want to redefine how it is processed. So this leads me to think that
the logic fork should still happen somewhere inside
It's not that easy as it sounds. BatchAction is born from BatchQuery (which
is in .query package and does not have access to DataDomain/Node) and
JDBCActionBuilder (which is logical part of JdbcAdapter, and also does not
have access to DataDomain/Node). After all, batch queries are public and can
b
I swiched to DataMap after I saw no quick access to DataDomain in
BatchAction class.
It all starts with DataDomainFlushAction, which has a reference to DD,
so there should be a way to inject factory down the tree.
I assume API changes in public classes of access.jdbc package are
allowed?
I swiched to DataMap after I saw no quick access to DataDomain in
BatchAction class. This needs futher investigation, we need to pass domain
there somehow. I assume API changes in public classes of access.jdbc package
are allowed?
2009/6/2 Andrus Adamchik
> Excellent. I have one comment (consist
Excellent. I have one comment (consistent with my position in the
previous message). Configuration of the factory below should be
attached to the stack objects (e.g. DataDomain), not the mapping
objects (DataMap):
+
+/**
+ * Sets factory for creating QueryBuilders
+ */
+publ
For not to be unsubstantiated, I uploaded my vision of the feature. Note
that there is no modeler support. It allows to provide custom factory that
creates builders of INSERT, UPDATE, DELETE queries. 'Soft-delete' factory is
included.
I do not say that 'soft delete' checkbox is not needed, but uplo
On Jun 2, 2009, at 2:54 PM, Andrey Razumovsky wrote:
But I'm no fan of adding some sort of 'soft' checkbox for dbattributes
I was suggesting marking entity with a "soft delete" checkbox (not
individual attribute - this would make no sense), and creating a
criteria based on qualifier that
I plan to add some default 'soft' strategy for everyone to use, and it will
likely have name of 'deleted' field as constructor parameter. But I'm no fan
of adding some sort of 'soft' checkbox for dbattributes, because it will
make new problems, such as handling several soft attributes and so on. Th
On 02/06/2009, at 8:08 PM, Andrus Adamchik wrote:
On Jun 2, 2009, at 12:29 PM, Aristedes Maniatis wrote:
1. Because the second most commonly used implementation will be:
* boolean NOT NULL field called 'isDeleted'
Could this alternative implementation be one of the 'out of the
box' choi
On Jun 2, 2009, at 12:29 PM, Aristedes Maniatis wrote:
1. Because the second most commonly used implementation will be:
* boolean NOT NULL field called 'isDeleted'
Could this alternative implementation be one of the 'out of the box'
choices? For us, we'd want that choice per table since so
On Jun 2, 2009, at 12:08 PM, Andrey Razumovsky wrote:
2. Deletion strategy for DataDomain. This means I do not always
fire
DeleteAction, but maybe something else (update action in my case).
Yeah, good idea to move this down the stack. I would love to have the
ObjectContext level code to
On 02/06/2009, at 7:08 PM, Andrey Razumovsky wrote:
Yeah, good idea to move this down the stack. I would love to have the
ObjectContext level code to stay unchanged, but then generate
UPDATE instead
of DELETE at the lower levels if entity is tagged as "soft delete".
I actually want to see
Hi,
> Back then, we
> could set up a delegate to intercept all queries, and I automatically
> added the restricting qualifier to each select query.
I'm afraid, simple qualifier would not be enough, I need to set them for all
joined tables in query (I have simple qualifirer already, by using ObjEn
On Jun 1, 2009, at 6:09 PM, Andrey Razumovsky wrote:
2. Deletion strategy for DataDomain. This means I do not always fire
DeleteAction, but maybe something else (update action in my case).
Yeah, good idea to move this down the stack. I would love to have the
ObjectContext level code to st
I have a legacy Cayenne 1.1.4 app that does the same thing.
I handled it back then by doing something similar. Back then, we
could set up a delegate to intercept all queries, and I automatically
added the restricting qualifier to each select query.
I never deleted from the application level code
Hi,
We've discussed this time ago, but I'm back now with some ideas.
Current situation:
I have to use special boolean column named "deleted" in all DB tables. That
is, I never (or very rarely) do something like "DELETE FROM ..." or
"context.deleteObject()", instead I do "UPDATE... SET deleted=tru
28 matches
Mail list logo
