Hm.... have you considered using runtime relationships? (NOTE: I've
never played with this, myself, so take the next bit with a grain of
salt. :)
In theory, it's entirely possible with cayenne to have a single
generic data object and then modify the mapping information at runtime
as necessary.
So... I /think/ you could do something along the following lines:
Register a global lifecycle listener that listens to whatever events
you need: in your case, I would say you probably need post-load and
pre-persist?
And then you can add the relationship information that you need or
that cayenne needs?
Then the info is there for cayenne to work with. And then you can use
the generic writeProperty/writeRelationship methods to access the
information in those properties as needed.
This might be a long shot...dunno... like I said... I haven't tried
it. But if I wanted to have relationships without having
relationships, this is likely the approach I would start looking at.
I'd be interested in hearing what others have to say... feasible given
the current cayenne stack?
Robert
On Apr 21, 2009, at 4/2111:44 AM , Joseph Schmidt wrote:
>> Hm. You're defining a relationship; I've always mapped
>> relationships aas relationships, and let Cayenne deal with the id
>> specifics. Note that cayenne won't force the creation foreign key
>> (although you should create one, if your db supports it).
>> You say you have "too many tables like that"... what order of
>> magnitude are you talking about?
> ~ 3/4 of the tables present in the scheme.
>
>> I think the upfront work of mapping relationships as relationships
>> will be worth it to you, long term.
> I do use ObjRelationships as they're discovered by the Cayenne
> Modeler at
> the reverse engineering step.
> Some tables however have "soft" relations to other
> tables(unfortunately with many tables). These "soft" relations are
> not modeled in the DB as FKs because it would mean to connect almost
> every table with too many other, and would just pollute the model
> (about efficiency not to mention).
> So what is required constantly by the business logic and the
> application, has FKs (and accordingly Cayenne ObjRelatinships
> discovede by CM), and the rest (for audit, or what external tools
> need, or very seldom cases) is using only by value - no FK constraint.
>
>> In terms of committing it all in the "same transaction", if you're
>> using myisam in mysql, it doesn't support true transactions, anyway.
> Yes, I'm aware :). I'm using MySQL only with InnoDB or other DBs
> that have "true" transactions :). The code in the parent was was
> just a quick example I got in reply to my message forward that this
> "would be a DB issue".
>
>> Anyway, if you /really/ want to deal with all of the nastiness of
>> id's, then I would think about using SQLTemplate.
>> You can script that using velocity directives and variables, so
>> then you may just wind up executing a query chain of SQLTemplates,
>> where the first template inserts into t_1 and the second template
>> in the chain inserts into t_2 per your requirements. If you really
>> want low-level jdbc-like functionality, SQLTemplate is the key.
> I don't :). I just need the IDs :). Most webapplications and REST like
> architectures need them anyway.
> I like the fact that I can simply save the entity T1 with Cayenne
> API. If I need to do SQL for it too, than I have no justification in
> front of the team to introduce Cayenne in the project in first
> place :(.
>
> thanks,
> Joseph.
>
This archive was generated by hypermail 2.0.0 : Tue Apr 21 2009 - 12:59:28 EDT