Wow - if I had known Andrus would be open to the "visible"/"invisible"
primary key idea I would have registered it in JIRA long ago.
I have to work with legacy tables where I need to use meaningful PKs -
and I have gotten by with
"getObjectId().getIdSnapshot().get(TEAM_ID_PK_COLUMN)" etc ... but I
would like the flexibility to Do It Wrong and have non-opaque PKs
available on some tables some of the time.
All in all, the ability to short circuit Cayenne's abstractions when
necessary (as with the Raw-SQL facilities) makes it much easier for me
to sell Cayenne to my colleagues.
So in my thinking a "visible PK" setting would mean that the PK would be
returned as a member in the objects comming back from queries, and it
would be a valid field to use in qualifier expressions. I would even be
so bold as to propose that the PK be permitted to be set in
inserts/updates (if I have asked for the freedom to do things wrong, why
not go all the way) - but I do not feel strongly about this.
cheers,
James
Andrus Adamchik wrote:
> Derek,
>
> I agree with all these suggestions and we should register them in JIRA.
> I can't guarantee that I will immediately add every checkbox that is
> requested, but these issues will still be helpful. When we have a
> critical mass of them coming from many users, we'll "refactor" them to
> form a consistent direction for the future Modeler.
>
> In fact I am already looking into support for "cut-and-paste" and for
> the navigation history in the modeler (I am thinking of "back" and
> "forward" buttons, just like the web browser). These should supersede
> (2) and (3), but specific usage patterns are still helpful.
>
> Same goes for the comments posted on "Modeler Question" thread by Kevin
> and Michael (Kevin already opened CAY-208, thanks!) - adding support for
> multiple objects selection in such operations as "sync", "delete", etc.
> is in the plans so having the specifics mentioned in JIRA should help to
> direct and expedite the implementation.
>
> Andrus
>
>
>
> On Oct 6, 2004, at 6:17 PM, Derek Rendall wrote:
>
>> As I have been working with the modeller I have thought of a few
>> things that would easy my task of creating a model for an existing DB.
>> Before creating JIRA issues on these, I thought it might be a good
>> idea to see what others have to say (and to make sure I have not
>> missed some existing feature that allows me to achieve what I want :-).
>>
>> (1) Ability (as a preference, particularly when reverse engineering?)
>> to treat string ids as meaningful attributes. I know from my EOF days
>> that meaningful ids are to be avoided, but sometimes they just make
>> life easier (or you have no choice :-). All the numeric ids I deal
>> with are meaningless, but the string ids are meaningful. For example,
>> our database has a number of key "type" lookup tables - having a
>> string as the PK saves lots of lookups on the DB for reports, summary
>> list displays etc. The type table in turn can contain data that aids
>> certain business processing logic based around the type (at which
>> point the lookup is not a big hit in the scheme of things). It also
>> enforces simple referential integrity.
>>
>> A possible extention would be to have a button that makes an object's
>> primary key "visible"/"invisible", with the option to ask that the
>> attributes in other objects that are fk links to this object become
>> "visible"/"invisible" as well.
>>
>> (2) The ability to push an attribute or relationship down to a
>> (specific) subclass or up to the superclass
>>
>> (3) The ability to go back to the previous entity that you were
>> editing. Ideally some sort of drop down with the latest 10 (number
>> configurable in preferences?) entities (object or database) where a
>> selection jumps automatically.
>>
>> Any comments? Shall I create JIRA entries for each of the above?
>>
>> Thanks
>>
>> Derek
>
>
>
This archive was generated by hypermail 2.0.0 : Fri Oct 08 2004 - 16:32:08 EDT