1

Topic: Usage of bins with the non-initialized data

I load the data from a DB in object with the fields corresponding to fields in a DB. In many cases all fields are not necessary and to load a subset of fields more optimally. But there is a risk that (especially further) fields are necessary still, and the code loading this data, forget to correct. It would be desirable, that this situation was explicit and the code broke as it is possible faster. It is possible to use such approach: class Person {private boolean nameInitialized; private String name; public String getName () {if (! nameInitialized) {throw new UninitializedPropertyException ("name");} return name;} public void setName (String name) {this.name = name; nameInitialized = true;} } It needs to be distinguished null from non-initialized value if in a DB can lie null. It is clear that if it is worked from Oracle, as non-initialized value it is possible to use "", if the field not null, null and , if it is a lot of fields more optimally to store fields in a bit grid, instead of separate boolean, in general is nuances everyones. Well and it is clear that manually to write such classes boringly. Whether there is a good library which solves this task of generation of such classes? Besides other it would be desirable still tracing of the changed fields (calls setXXX) for homebrew ORM. As I it see - the programmer describes the interface or the abstract class of a type public abstract class Person {public abstract String getName (); public abstract String setName (String name);} Person person = something.create (Person.class); and the library already generates and returns appropriate implementation.

2

Re: Usage of bins with the non-initialized data

Hello, vsb, you wrote: vsb> I load the data in object with the fields corresponding to fields in <...>. In many cases all fields are not necessary and to load a subset of fields more optimally. But there is a risk that (especially further) fields are necessary still, and the code loading this data, forget to correct. It would be desirable, that this situation was explicit and the code broke as it is possible faster. vsb> <...> in general there are nuances everyones. Well and it is clear that manually to write such classes boringly vsb> As I it I see - the programmer describes the interface or the abstract class of a type vsb> public abstract class Person {vsb> public abstract String getName (); vsb> public abstract String setName (String name); vsb>} vsb> Person person = something.create (Person.class); vsb> and the library already generates and returns appropriate implementation. Once for a long time about 10 years ago I solved the similar task with reference to fuss with data structures on TR-069 protocol where too it would be desirable to turn as much as possible close the java-party to a monkey with a grenade to colleagues-experts first of all on the equipment, instead of programming. Rather comprehensible prototype further which, unfortunately business is not went, has been based on a combination of the annotated classes with the annotated fields, on which else in compile/instrumentation-time the aspect,  necessary mixin was transversed, allowing to build in operation on () serializations of the specific data in small core, owning the general understanding of the protocol. Now it seems to me that I collected it alone approximately for a month and so long I pottered only because it there was my first scale experience of struggle against aspects. Somewhere even source codes should remain, jboss aop-specific.

3

Re: Usage of bins with the non-initialized data

4

Re: Usage of bins with the non-initialized data

5

Re: Usage of bins with the non-initialized data

Hello, vsb, you wrote: vsb> I load the data from a DB in object with the fields corresponding to fields in a DB. In many cases all fields are not necessary and to load a subset of fields more optimally. But there is a risk that (especially further) fields are necessary still, and the code loading this data, forget to correct. To make dto with necessary  fields. Kiss.