Re: [Lmappletserver-developers] Primary keys for search, report and schedule

[Peter S. <co...@pe...>]

Hi Roberto, (Jon)

Forget about this previous request, I've now done my implementation using
the existing setup with names as primary keys, and I'm quite happy with it
as it is.

In my application I use a custom PersistenceProvider (
javax.persistence.PersistenceProvider) on top of hibernate that intercepts
the ejb sql generated by the SearchManagerBean, and rewrite the where part
of the sql to apply my applications security constraints. In the name I
concat a userid, showing that the search belongs to the specific user, works
like a charm...

regards,

Peter



On Jan 16, 2008 11:43 AM, Peter Salomonsen <co...@pe...>
wrote:

> Hi Roberto, (Jon)
>
> Today I see that search, report and schedule uses names as their primary
> keys. In my application I want to join with these tables, since I want to
> connect it to a user/customer table so they could have their own searches.
>
> Using strings as primary keys, two users could not have searches with the
> same name, which could be confusing since they are not supposed to see each
> others searches. I can solve this by inserting the userid in the search name
> string - and I think it will work fine, but would not be the most beautiful
> database design.
>
> I'm wondering about the consequences if we introduced a numeric primary
> key for all these tables. Relations between search/report/schedule would
> then have to be by numeric id - but would it have any other effects? Would
> it be a bad idea to change this?
>
> regards,
>
> Peter
>