org.jclarion.clarion.view
Class ClarionView
java.lang.Object
org.jclarion.clarion.PropertyObject
org.jclarion.clarion.view.ClarionView
- All Implemented Interfaces:
- ViewField
public class ClarionView
- extends PropertyObject
- implements ViewField
Model a clarion view
Some observations from experiments with views in clarion 5.5 and
resulting SQL sent to postgres:
When no order is indicated - select is not sorted
Use of positioning etc has not effect reset will reset from top
Ordering is critical for positioning etc. Clarion assumes that
order defines a unique position. We will too
changes to prop:order take effect on next set()
Calling reset(view,file) will trigger reset based on position
inferred in file buffers taking changes to prop:order etc into
consideration. Clarion also forces a read on the table(s) in question
( their primary keys?)
Calling reset(view,int) does *not* do what clarion documentation implies
and what I originally coded this object to do. Calling reset is very similar
to calling reset(view,file) except trailing fields in key are zeroed out
calling getposition(), change prop:order call reset(view,string)
works same as above. Clarion must be encoding more than just ordering
data. From help files - clarion says it encodes data relating to
primary key fields. So position for views encodes PK data only.
Presumably - this is all view needs - pk data. Everything else can
be derived from there.
All fields in a table that are keyed are implicitly included as
part of the project list
reget must call get on every underlying file
Implementation of this is to just create a dynamic ClarionSQLFile
object with an overloaded open() method where we synthesize the
FileState object to represent a more sophisticated table structure
and then methods like next() etc here become simple wrappers for the
underlying dynamically create file
Items:
Limitiations:
* Will not handle having tables appear more than once in structre
Clarion system did not handle this well either - i.e. no way
to differentiate tables thus selected.
* no intention of implementing mutators like put() etc just yet.
to do this: 1) save changed params. Call reget() on primary file
Restroe changed params. put()
* outer joins and positions will not work due to absence of facility
to record position of nullable parameters in ClarionSQLFile right now.
Is doable - but tricky because of fact that comparators in ANSI SQL
do not play nice with nullable columns
* will only work for all File types are SQL
* will only work if all file types share same source
TODO - implement view solution that can cross non SQL implementations
and different sources.
- Author:
- barney
| Methods inherited from class org.jclarion.clarion.PropertyObject |
addListener, canNotifyLocalChange, clearMetaData, debugMetaData, getDebugMetaData, getDebugMetaData, getId, getInheritedProperty, getProperty, getProperty, getProperty, getProperty, getPropertyOrDefault, getRawProperty, getRawProperty, getSetProperties, isProperty, isSettable, reMap, removeAllListeners, removeListener, setClonedProperty, setClonedProperty, setClonedProperty, setClonedProperty, setClonedProperty, setId, setProperty, setProperty, setProperty, setProperty, setProperty, toString |
| Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait |
ClarionView
public ClarionView()
add
public void add(ViewJoin aTable)
add
public void add(ViewProject aProject)
setTable
public void setTable(ClarionFile aFile)
setOrder
public void setOrder(java.lang.String order)
setFilter
public void setFilter(java.lang.String filter)
open
public void open()
close
public void close()
delete
public void delete()
put
public void put()
set
public void set()
flush
public void flush()
records
public int records()
- Not really clear when is a good time to call records
Should we regenerate filters as part of record get
or assume this has already happened?
Will err on side of no regeneration.
Another problem - what about client side filters?
They will not be taken into consideration. Will consider
this one to be ok - if anyone wants an accurate count of
actual records - they need to iterate over them
- Returns:
set
public void set(int sortOffset)
next
public void next()
iterate
protected void iterate(int dir)
watch
public void watch()
getPosition
public ClarionString getPosition()
reset
public void reset(ClarionString position)
- Reset based on indicated position
Essentially - reget() following by a reset(file)
- Parameters:
position -
reget
public void reget(ClarionString position)
reset
public void reset(ClarionFile position)
- Reset based on current order parameter's directly from
ClarionFile buffers
- Parameters:
position -
previous
public void previous()
buffer
public void buffer(java.lang.Integer pagesize,
java.lang.Integer behind,
java.lang.Integer ahead,
java.lang.Integer timeout)
getFile
public ClarionFile getFile(int indx)
getParentPropertyObject
public PropertyObject getParentPropertyObject()
- Specified by:
getParentPropertyObject in class PropertyObject
getLocalProperty
public ClarionObject getLocalProperty(int index)
- Overrides:
getLocalProperty in class PropertyObject
notifyLocalChange
protected void notifyLocalChange(int indx,
ClarionObject value)
- Overrides:
notifyLocalChange in class PropertyObject
getFileForField
public ClarionFile getFileForField(int indx)
getFileIndexForField
public int getFileIndexForField(int indx)
debugMetaData
protected void debugMetaData(java.lang.StringBuilder sb)
- Specified by:
debugMetaData in class PropertyObject
getField
public ClarionObject getField()
- Specified by:
getField in interface ViewField
getSubFields
public java.lang.Iterable<ViewField> getSubFields()
- Specified by:
getSubFields in interface ViewField
Copyright © 2010. All Rights Reserved.