Not sure if this is going to add much to the conversation, but I know Hibernate uses -1 on a Bean to indicate that it had not been persisted yet. Once the Hibernate engine inserted the object or retrieved the object from the DB the -1 was replaced with whatever Id was returned by the DB. String Ids (or joint keys --which would be marshalled to their own Beans representing the key) started with a value of null. Using Hibernate, the easiest way to see if an object had been persisted was just to check if the id was -1 or null depending on the key type. Additionally, if the Bean couldn't be updated or saved an exception was thrown, but I like the true/false better.
Cheers, Tyler On 6/26/06, Geert Bevin <[EMAIL PROTECTED]> wrote:
Hi Steven, Actually the API that you're suggesting here will not work. The reason is that -1 indicates that the saving or updating wasn't successful. I'm now wondering if the API shouldn't be changed so that instead of returning the identifier value, a boolean value is returned instead (indicating success or failure). The identifier value can always be obtained by using the getIdentifierValue method (with just a Number or maybe even Object as a return type), or even by using the object's property getter directly. Thanks a lot for the work that you put into improving the authentication documentation. I think it is indeed in a much better shape now and hope that for other newcomers it will not be as arcane as it was to you. Take care, Geert On 24 Jun 2006, at 08:29, Steven Grimm wrote: > Geert Bevin wrote: >> Adding support for it with a BeanType restore(long) method is no >> problem at all, however it's less easy with int update(BeanType >> bean), int save(BeanType bean) and int getIdentifierValue(BeanType >> bean) since you can just overload primitive return types. I sadly >> can't really think of an elegant solution besides creating a >> GenericQueryManagerLong interface and all the related classes, or >> using the Number interface instead where int is used. Not sure >> about the performance of the latter though since objects will have >> to be created for each and every use of identifier values. >> Suggestions about how to solve this are very welcome! > > I'm not sure if it counts as "elegant," but something like this > would at least be functional: > > - Add BeanType restore(long) as you suggest. Maybe also BeanType > restore(Number). > - Add <T extends Number> getIdentifierValue(BeanType bean, Class<T> > idType) to return an identifier of any type. (Does it make sense to > support String identifiers too?) > - Alternately, or perhaps in addition, add getIdentifierValueLong > (BeanType bean) to avoid the object creation. > - For update and insert, if the identifier type is something other > than int, make them return -1. Add a new method <T extends Number> > getLastIdentifier(Class<T> idType) and/or getLastIdentifierLong() > that returns the identifier from the most recent call. > >> RifeConfig.Authentication.getTableUser() should give you that. > > Super, that works perfectly. I've updated the database user > examples in the user's guide cookbook. > > I have also updated that page to include an example of reading > additional user data, which I realized I didn't do the first time > around. I think the database user docs are now at a point where I > wouldn't have been frustrated by them. (But I no longer have the > perspective of someone who's brand new to the subject; I guess time > will tell if the docs are sufficient to get someone new up to speed.) > > -Steve > _______________________________________________ > Rife-users mailing list > [email protected] > http://lists.uwyn.com/mailman/listinfo/rife-users > -- Geert Bevin Uwyn "Use what you need" - http://uwyn.com RIFE Java application framework - http://rifers.org Music and words - http://gbevin.com _______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
_______________________________________________ Rife-users mailing list [email protected] http://lists.uwyn.com/mailman/listinfo/rife-users
