Mike,

The Data Access Layer page[1] have the answer to this.   Specifically this 
particular part in the example.

    // getters and setters must follow the Java
    // convention of putting get/set in front of
    // the field name.
    public String getText() {
        return text;
    }

get_iscsiName is not a Java coding convention.  We should not use it.  The 
coding convention is "get" followed by the variable name with the first 
character capitalized.

--Alex
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Data+Access+Layer


> -----Original Message-----
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Friday, June 7, 2013 3:12 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Quick DB Question
> 
> Hi,
> 
> Yeah, I should have been more explicit in what problem I was seeing. :)
> 
> What I'm seeing is that I set the field with a string (IQN) that is not null, 
> but it
> doesn't make it to the DB.
> 
> I have other, similar "sets" and all is well with them (their data make it to 
> the
> DB just fine).
> 
> Perhaps it's getting overwritten later in the processing with a null. I'll 
> have to
> look into it more.
> 
> I'm actually on master, as well. I do see an "iscsi_name" field.
> varchar(255) in the cloud.volumes table. I haven't updated in a week or so,
> but I doubt the column's been removed. Strange.
> 
> I'm developing a storage plug-in which creates an iSCSI volume on a SAN and
> I just wanted to use (what I thought was) an existing column to store the IQN.
> It looked like the "iscsi_name" column would be a good place to store this
> info.
> 
> Thanks!
> 
> 
> On Fri, Jun 7, 2013 at 4:05 PM, Vijayendra Bhamidipati <
> vijayendra.bhamidip...@citrix.com> wrote:
> 
> > Hi Mike,
> >
> > You're probably calling those setter methods in the constructor and I
> > don't see any problem having an '_' in the function name. What is the
> > problem you're seeing?
> >
> > Also I don't see this iscsi_name in VolumeVO.java on master - I'm
> > guessing you're working off a private branch.
> >
> > I'm yet to go through your earlier mails on the alias - so sorry for
> > the following question if it has already been discussed - why do you
> > want to put an iscsi iqn here in volumeVO? Isn't it better to put in a
> > class of its own that derives VolumeVO?
> >
> > Regards,
> > Vijay
> >
> > -----Original Message-----
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Friday, June 07, 2013 2:52 PM
> > To: dev@cloudstack.apache.org
> > Subject: Quick DB Question
> >
> > Hi,
> >
> > I'd like to place an IQN in the "iscsi_name" field available in the
> > cloud.volumes table after I create an appropriate iSCSI target on a SAN.
> >
> > For some reason, we don't seem to be using this column in the VolumeVO
> > class, so I went ahead and added access to it.
> >
> > I've successfully added columns to tables before in CloudStack and
> > created read/write access to them, but I am - for some reason - having
> > trouble with this "iscsi_name" column.
> >
> > In the VolumeVO class, I've added the following (below). Can anyone
> > see any flaws in what I've done? I could have made the member variable
> > private (I just copied, pasted, and modified an existing field), but
> > that shouldn't matter for this purpose. I don't usually use the "_" in
> > a method name, but it just looked better to me in this case.
> >
> > Thanks!
> >
> >     @Column(name = "iscsi_name")
> >
> >     String iScsiName;
> >
> >
> >     @Override
> >
> >     public String get_iScsiName() {
> >
> >     return this.iScsiName;
> >
> >     }
> >
> >
> >
> >     public void set_iScsiName(String iScsiName) {
> >
> >     this.iScsiName = iScsiName;
> >
> >     }
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud<http://solidfire.com/solution/overview/?video=play>
> > *(tm)*
> >
> 
> 
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *(tm)*

Reply via email to