Question on filtering/sorting was Re: Question about code table handling
- I dont think there is anything that can be done for
filtering/sorting/searching using Jaxor. As far as I know , there are
no provisions for doing this in Jaxor and I think it is out of
context/scope for Jaxor. If you want similar functionality, after you
get particular rows to be displayed, you might use XML/XSL parsers to
filter/sort on the client side.
--- In agileDatabases@yahoogroups.com, "ginanjar_utama"
> --- In agileDatabases@yahoogroups.com, "psadalage" <psadalage@y...>acts
> > We tend to use a code table.
> > the structure of which may be something like this
> > CodeType
> > Code
> > Value
> and CodeType has its own mapper right ?
> > CodeType: is a description of the Type of Code it is and also
> > as a filtering criteria.ofcourse
> > Code: is the PK.
> > Value is the value for this code.
> > So we can store all the AddressTypes, States, Name Prefix, Name
> > Suffix etc.. in one table.
> > This approach makes the data model less complex, keeps all the
> > data needed for the app in one place and hence can be cached very
> > easily.
> > The data in these tables can be used to generate static/constant
> > classes.
> > Pramod
> I wonder how to use filtering/sorting on the fly with jaxor?
> Suppose i give an HTML user interface to search, filter with status
> and type, sort with account number/etc in a CustomerList and
> a submit button.
> Jaxor use a good cache method so it will be not much matter
> whether you will do it in the collection or in the SQL Query.
> So how do we deal with the combination of search/filter/sort using
> SQL Query?
> Sorry if this is OOT.
> Ginanjar Utama
>> Ouch. I have seen this approach in some legacy applications. Withthe code table, your queries get monstrous and relationships cannot
be enforced. You can't build a relationship like "this field must
uniquely exist in the lookup table, but only for a value of the code
... and to add to the list:
1) Since you have to use the largest possible string datatype to
hold the codes, present and future, you waste space.
2) Since you have to use the largest possible string datatype to
hold the codes, present and future, you waste time doing CAST()
3) The single monster CHECK() constraint that has to enforce the
syntax or check digits on ALL the various codes in the same table
are even worse than the query code.
The usual result is that the code table has no constraints except
perhaps a primary key (code_name, code). And that means that you
are just waiting for the data to get corrupted.
- I dont exactly remember which mail of Pramod you got
this from, only imagining that he would be talking abt
the famous code table in our system, I would like to
tell you that it is a alphanumeric column, it can
contain text and numbers.
I write this, because Pramod is on leave.
--- aweatherall2003 <alexweatherall@...>
> >> Value is the value for this code.
> What datatype do you use for the value field? Is the
> value always
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software